2.1作为函数的箭头

2.1 Arrows as Functions

这已经是太多抽象的废话了吗？不要灰心。我们来谈谈具体的吧。将箭头（也称为态射）视为函数。您有一个函数 f，它接受 A 类型的参数并返回 B。您还有另一个函数 g，它接受 B 并返回 C。您可以通过将 f 的结果传递给 g 来组合它们。您刚刚定义了一个接受 A 并返回 C 的新函数。

Is this already too much abstract nonsense? Do not despair. Let’s talk concretes. Think of arrows, which are also called morphisms, as functions. You have a function f that takes an argument of type A and returns a B. You have another function g that takes a B and returns a C. You can compose them by passing the result of f to g. You have just defined a new function that takes an A and returns a C.

在数学中，这种组合由函数之间的小圆圈表示：g∘f。注意从右到左的构图顺序。对于某些人来说，这令人困惑。您可能熟悉 Unix 中的管道表示法，如下所示：

In math, such composition is denoted by a small circle between functions: g∘f. Notice the right to left order of composition. For some people this is confusing. You may be familiar with the pipe notation in Unix, as in:

lsof | grep Chrome

lsof | grep Chrome

或 F# 中的 V 形符号>>，两者都是从左到右。但在数学和 Haskell 中，函数是从右到左组合的。如果您将 g∘f 读作“ f之后的g ”，将会有所帮助。

or the chevron >> in F#, which both go from left to right. But in mathematics and in Haskell functions compose right to left. It helps if you read g∘f as “g after f.”

让我们通过编写一些 C 代码来使这一点更加明确。我们有一个函数f，它接受一个类型的参数A并返回一个类型的值B：

Let’s make this even more explicit by writing some C code. We have one function f that takes an argument of type A and returns a value of type B:

B f(A a);

B f(A a);

另一个：

and another:

C g(B b);

C g(B b);

它们的组成是：

Their composition is:

C g_after_f(A a)
{
    return g(f(a));
}

C g_after_f(A a)
{
    return g(f(a));
}

在这里，您再次看到从右到左的组合：g(f(a)); 这次在C。

Here, again, you see right-to-left composition: g(f(a)); this time in C.

我希望我能告诉您，C++ 标准库中有一个模板，它接受两个函数并返回它们的组合，但是没有一个模板。所以让我们尝试一些 Haskell 来改变一下。这是从 A 到 B 的函数声明：

I wish I could tell you that there is a template in the C++ Standard Library that takes two functions and returns their composition, but there isn’t one. So let’s try some Haskell for a change. Here’s the declaration of a function from A to B:

f :: A -> B

f :: A -> B

相似地：

Similarly:

g :: B -> C

g :: B -> C

它们的组成是：

Their composition is:

g . f

g . f

一旦你看到 Haskell 中的事情有多么简单，你就会发现无法用 C++ 表达简单的函数概念会有点尴尬。事实上，Haskell 允许你使用 Unicode 字符，这样你就可以将组合写成：

Once you see how simple things are in Haskell, the inability to express straightforward functional concepts in C++ is a little embarrassing. In fact, Haskell will let you use Unicode characters so you can write composition as:

g ∘ f

g ∘ f

您甚至可以使用 Unicode 双冒号和箭头：

You can even use Unicode double colons and arrows:

f ∷ A → B

f ∷ A → B

这是 Haskell 的第一课：双冒号表示“具有……的类型” 函数类型是通过在两个类型之间插入箭头来创建的。通过在两个函数之间插入句点（或 Unicode 圆圈）来组成两个函数。

So here’s the first Haskell lesson: Double colon means “has the type of…” A function type is created by inserting an arrow between two types. You compose two functions by inserting a period between them (or a Unicode circle).

2.2组合物的性质

2.2 Properties of Composition

任何范畴的组合物都必须满足两个极其重要的属性。

There are two extremely important properties that the composition in any category must satisfy.

1. 组合具有结合性。如果您有三个可组合的态射 f、g 和 h（即它们的对象端到端匹配），则不需要括号来组合它们。用数学符号表示为：

1. Composition is associative. If you have three morphisms, f, g, and h, that can be composed (that is, their objects match end-to-end), you don’t need parentheses to compose them. In math notation this is expressed as:

h∘(g∘f) = (h∘g)∘f = h∘g∘f

h∘(g∘f) = (h∘g)∘f = h∘g∘f

在（伪）Haskell 中：

In (pseudo) Haskell:

f :: A -> B
g :: B -> C
h :: C -> D
h . (g . f) == (h . g) . f == h . g . f

f :: A -> B
g :: B -> C
h :: C -> D
h . (g . f) == (h . g) . f == h . g . f

（我说“伪”，因为没有为函数定义相等性。）

(I said “pseudo,” because equality is not defined for functions.)

结合性在处理函数时非常明显，但在其他范畴中可能不那么明显。

Associativity is pretty obvious when dealing with functions, but it may be not as obvious in other categories.

2. 对于每个对象 A 都有一个箭头，它是一个组合单元。该箭头从对象循环到自身。作为组合单位意味着，当与分别从 A 开始或以 A 结束的任何箭头组合时，它会返回相同的箭头。对象 A 的单位箭头称为 id _A（A 上的身份）。用数学表示法来说，如果 f 从 A 到 B 那么

2. For every object A there is an arrow which is a unit of composition. This arrow loops from the object to itself. Being a unit of composition means that, when composed with any arrow that either starts at A or ends at A, respectively, it gives back the same arrow. The unit arrow for object A is called id_A (identity on A). In math notation, if f goes from A to B then

f∘idA = f

f∘idA = f

和

and

idB∘f = f

idB∘f = f

在处理函数时，恒等箭头被实现为仅返回其参数的恒等函数。每种类型的实现都是相同的，这意味着该函数是普遍多态的。在 C++ 中我们可以将其定义为模板：

When dealing with functions, the identity arrow is implemented as the identity function that just returns back its argument. The implementation is the same for every type, which means this function is universally polymorphic. In C++ we could define it as a template:

template T id(T x) { return x; }

template T id(T x) { return x; }

当然，在 C++ 中没有那么简单，因为您不仅要考虑传递的内容，还要考虑传递的方式（即按值、按引用、按常量引用、按移动等）。

Of course, in C++ nothing is that simple, because you have to take into account not only what you’re passing but also how (that is, by value, by reference, by const reference, by move, and so on).

在 Haskell 中，恒等函数是标准库的一部分（称为 Prelude）。这是它的声明和定义：

In Haskell, the identity function is part of the standard library (called Prelude). Here’s its declaration and definition:

id :: a -> a
id x = x

id :: a -> a
id x = x

正如你所看到的，Haskell 中的多态函数是小菜一碟。在声明中，您只需将类型替换为类型变量即可。技巧如下：具体类型的名称始终以大写字母开头，类型变量的名称以小写字母开头。所以这里a代表所有类型。

As you can see, polymorphic functions in Haskell are a piece of cake. In the declaration, you just replace the type with a type variable. Here’s the trick: names of concrete types always start with a capital letter, names of type variables start with a lowercase letter. So here a stands for all types.

Haskell 函数定义由函数名称和形式参数组成——这里只有一个x. 函数体跟在等号后面。这种简洁常常会让新手感到震惊，但你很快就会发现它很有道理。函数定义和函数调用是函数式编程的基础，因此它们的语法被减少到最低限度。不仅参数列表周围没有括号，而且参数之间也没有逗号（稍后，当我们定义多个参数的函数时，您会看到这一点）。

Haskell function definitions consist of the name of the function followed by formal parameters — here just one, x. The body of the function follows the equal sign. This terseness is often shocking to newcomers but you will quickly see that it makes perfect sense. Function definition and function call are the bread and butter of functional programming so their syntax is reduced to the bare minimum. Not only are there no parentheses around the argument list but there are no commas between arguments (you’ll see that later, when we define functions of multiple arguments).

函数体始终是一个表达式——函数中没有语句。函数的结果就是这个表达式——这里只是x。

The body of a function is always an expression — there are no statements in functions. The result of a function is this expression — here, just x.

我们的第二节 Haskell 课程到此结束。

This concludes our second Haskell lesson.

恒等条件可以写成（同样，用伪 Haskell）：

The identity conditions can be written (again, in pseudo-Haskell) as:

f . id == f
id . f == f

f . id == f
id . f == f

您可能会问自己这样一个问题：为什么有人会为恒等函数（一个什么都不做的函数）烦恼？话又说回来，我们为什么要为数字零烦恼呢？零是无意义的象征。古罗马人有一种没有零的数字系统，他们能够建造出色的道路和渡槽，其中一些至今仍存在。

You might be asking yourself the question: Why would anyone bother with the identity function — a function that does nothing? Then again, why do we bother with the number zero? Zero is a symbol for nothing. Ancient Romans had a number system without a zero and they were able to build excellent roads and aqueducts, some of which survive to this day.

中性值（例如零）或id在处理符号变量时非常有用。这就是为什么罗马人不太擅长代数，而熟悉零概念的阿拉伯人和波斯人却很擅长。因此，恒等函数作为高阶函数的参数或返回变得非常方便。高阶函数使得函数的符号操作成为可能。它们是函数的代数。

Neutral values like zero or id are extremely useful when working with symbolic variables. That’s why Romans were not very good at algebra, whereas the Arabs and the Persians, who were familiar with the concept of zero, were. So the identity function becomes very handy as an argument to, or a return from, a higher-order function. Higher order functions are what make symbolic manipulation of functions possible. They are the algebra of functions.

总结一下：范畴由对象和箭头（态射）组成。箭头可以组合，并且组合是关联的。每个对象都有一个恒等箭头，充当组合下的一个单元。

To summarize: A category consists of objects and arrows (morphisms). Arrows can be composed, and the composition is associative. Every object has an identity arrow that serves as a unit under composition.

2.3组合是编程的本质

2.3 Composition is the Essence of Programming

函数式程序员有一种独特的处理问题的方式。他们首先提出非常禅宗般的问题。比如设计一个交互程序时，他们会问：什么是交互？在实施康威的生命游戏时，他们可能会思考生命的意义。本着这种精神，我要问：什么是编程？在最基本的层面上，编程就是告诉计算机要做什么。“取出内存地址x的内容并将其添加到寄存器EAX的内容中。” 但即使我们用汇编语言编程，我们给计算机的指令也是更有意义的表达。我们正在解决一个不平凡的问题（如果它是微不足道的，我们就不需要计算机的帮助）。以及我们如何解决问题？我们将更大的问题分解为更小的问题。如果较小的问题仍然太大，我们会进一步分解它们，依此类推。最后，我们编写解决所有小问题的代码。然后是编程的本质：我们编写这些代码片段来创建更大问题的解决方案。如果我们无法将碎片重新组合在一起，那么分解就没有意义。

Functional programmers have a peculiar way of approaching problems. They start by asking very Zen-like questions. For instance, when designing an interactive program, they would ask: What is interaction? When implementing Conway’s Game of Life, they would probably ponder about the meaning of life. In this spirit, I’m going to ask: What is programming? At the most basic level, programming is about telling the computer what to do. “Take the contents of memory address x and add it to the contents of the register EAX.” But even when we program in assembly, the instructions we give the computer are an expression of something more meaningful. We are solving a non-trivial problem (if it were trivial, we wouldn’t need the help of the computer). And how do we solve problems? We decompose bigger problems into smaller problems. If the smaller problems are still too big, we decompose them further, and so on. Finally, we write code that solves all the small problems. And then comes the essence of programming: we compose those pieces of code to create solutions to larger problems. Decomposition wouldn’t make sense if we weren’t able to put the pieces back together.

这种层次分解和重组的过程并不是计算机强加给我们的。它反映了人类思维的局限性。我们的大脑一次只能处理少量的概念。心理学中被引用最多的论文之一《神奇的数字七，加或减二》假设我们只能在脑海中保留 7±2 个“块”信息。我们对人类短期记忆的理解细节可能正在发生变化，但我们确信它是有限的。最重要的是，我们无法处理大量的对象或意大利面条般的代码。我们需要结构，并不是因为结构良好的程序看起来赏心悦目，而是因为否则我们的大脑就无法有效地处理它们。我们经常将某些代码描述为优雅或美丽，但我们真正的意思是它很容易被我们有限的人类思维处理。优雅的代码会创建大小合适、数量合适的块，以便我们的心理消化系统吸收它们。

This process of hierarchical decomposition and recomposition is not imposed on us by computers. It reflects the limitations of the human mind. Our brains can only deal with a small number of concepts at a time. One of the most cited papers in psychology, The Magical Number Seven, Plus or Minus Two, postulated that we can only keep 7 ± 2 “chunks” of information in our minds. The details of our understanding of the human short-term memory might be changing, but we know for sure that it’s limited. The bottom line is that we are unable to deal with the soup of objects or the spaghetti of code. We need structure not because well-structured programs are pleasant to look at, but because otherwise our brains can’t process them efficiently. We often describe some piece of code as elegant or beautiful, but what we really mean is that it’s easy to process by our limited human minds. Elegant code creates chunks that are just the right size and come in just the right number for our mental digestive system to assimilate them.

那么组成程序的正确块是什么？它们的表面积的增加速度必须慢于其体积的增加速度。（我喜欢这个类比，因为我的直觉是，几何物体的表面积随其尺寸的平方而增长——比体积随其尺寸的立方而增长的速度慢。）表面积是我们需要的信息组成块。体积是我们实现它们所需的信息。这个想法是，一旦实现了一个块，我们就可以忘记其实现的细节，而专注于它如何与其他块交互。在面向对象编程中，表面是对象的类声明，或其抽象接口。在函数式编程中，它是函数的声明。（我稍微简化了一些事情，但这就是要点。）

So what are the right chunks for the composition of programs? Their surface area has to increase slower than their volume. (I like this analogy because of the intuition that the surface area of a geometric object grows with the square of its size — slower than the volume, which grows with the cube of its size.) The surface area is the information we need in order to compose chunks. The volume is the information we need in order to implement them. The idea is that, once a chunk is implemented, we can forget about the details of its implementation and concentrate on how it interacts with other chunks. In object-oriented programming, the surface is the class declaration of the object, or its abstract interface. In functional programming, it’s the declaration of a function. (I’m simplifying things a bit, but that’s the gist of it.)

范畴论是极端的，因为它积极阻止我们观察对象的内部。范畴论中的对象是一个抽象的模糊实体。你所能知道的就是它如何与其他对象相关——它如何使用箭头与它们连接。这就是互联网搜索引擎通过分析传入和传出链接对网站进行排名的方式（除非它们作弊）。在面向对象编程中，理想化的对象只能通过其抽象接口（纯表面，无体积）可见，方法扮演箭头的角色。当您必须深入研究对象的实现以了解如何将其与其他对象组合时，您就失去了编程范例的优势。

Category theory is extreme in the sense that it actively discourages us from looking inside the objects. An object in category theory is an abstract nebulous entity. All you can ever know about it is how it relates to other object — how it connects with them using arrows. This is how internet search engines rank web sites by analyzing incoming and outgoing links (except when they cheat). In object-oriented programming, an idealized object is only visible through its abstract interface (pure surface, no volume), with methods playing the role of arrows. The moment you have to dig into the implementation of the object in order to understand how to compose it with other objects, you’ve lost the advantages of your programming paradigm.

2.4挑战

2.4 Challenges

1. 尽可能用您最喜欢的语言（或者第二喜欢的语言，如果您最喜欢的语言恰好是 Haskell）实现恒等函数。
2. Implement, as best as you can, the identity function in your favorite language (or the second favorite, if your favorite language happens to be Haskell).
3. 用您喜欢的语言实现组合功能。它接受两个函数作为参数并返回一个由它们组成的函数。
4. Implement the composition function in your favorite language. It takes two functions as arguments and returns a function that is their composition.
5. 编写一个程序来尝试测试您的组合函数是否尊重身份。
6. Write a program that tries to test that your composition function respects identity.
7. 万维网在某种意义上是一个范畴吗？链接是态射吗？
8. Is the world-wide web a category in any sense? Are links morphisms?
9. Facebook 是一个以人为对象、以友谊为态射的范畴吗？
10. Is Facebook a category, with people as objects and friendships as morphisms?
11. 有向图什么时候是范畴？
12. When is a directed graph a category?

3.1谁需要类型？

3.1 Who Needs Types?

关于静态与动态以及强类型与弱类型的优点似乎存在一些争议。让我用一个思想实验来说明这些选择。想象一下，数以百万计的猴子在电脑键盘上愉快地敲击随机按键，生成程序、编译和运行它们。

There seems to be some controversy about the advantages of static vs. dynamic and strong vs. weak typing. Let me illustrate these choices with a thought experiment. Imagine millions of monkeys at computer keyboards happily hitting random keys, producing programs, compiling, and running them.

使用机器语言，猴子产生的任何字节组合都将被接受并运行。但对于高级语言，我们确实很欣赏编译器能够检测词汇和语法错误的事实。很多猴子会没有香蕉，但剩下的程序将有更好的机会发挥作用。类型检查为无意义的程序提供了另一个障碍。此外，在动态类型语言中，类型不匹配会在运行时被发现，而在强类型静态检查语言中，类型不匹配是在编译时发现的，从而在有机会运行之前消除大量不正确的程序。

With machine language, any combination of bytes produced by monkeys would be accepted and run. But with higher level languages, we do appreciate the fact that a compiler is able to detect lexical and grammatical errors. Lots of monkeys will go without bananas, but the remaining programs will have a better chance of being useful. Type checking provides yet another barrier against nonsensical programs. Moreover, whereas in a dynamically typed language, type mismatches would be discovered at runtime, in strongly typed statically checked languages type mismatches are discovered at compile time, eliminating lots of incorrect programs before they have a chance to run.

那么问题来了，我们是想让猴子开心，还是想制作出正确的程序？

So the question is, do we want to make monkeys happy, or do we want to produce correct programs?

打字猴思维实验的通常目标是制作莎士比亚全集。在循环中使用拼写检查器和语法检查器将大大增加可能性。类型检查器的类比可以更进一步，确保一旦罗密欧被宣布为人类，他不会在其强大的引力场中发芽或捕获光子。

The usual goal in the typing monkeys thought experiment is the production of the complete works of Shakespeare. Having a spell checker and a grammar checker in the loop would drastically increase the odds. The analog of a type checker would go even further by making sure that, once Romeo is declared a human being, he doesn’t sprout leaves or trap photons in his powerful gravitational field.

3.2类型与可组合性有关

3.2 Types Are About Composability

范畴论是关于组合箭头的。但任意两个箭头都不能组合。一个箭头的目标对象必须与下一个箭头的源源对象相同。在编程中，我们将一个函数的结果传递给另一个函数。如果目标函数无法正确解释源函数生成的数据，则程序将无法运行。两端必须适合组合物才能发挥作用。语言的类型系统越强大，这种匹配的描述和机械验证就越好。

Category theory is about composing arrows. But not any two arrows can be composed. The target object of one arrow must be the same as the source source object of the next arrow. In programming we pass the results on one function to another. The program will not work if the target function is not able to correctly interpret the data produced by the source function. The two ends must fit for the composition to work. The stronger the type system of the language, the better this match can be described and mechanically verified.

我听到的反对强静态类型检查的唯一严肃的论点是，它可能会消除一些语义上正确的程序。实际上，这种情况很少发生，并且无论如何，每种语言都会在确实有必要时提供某种后门来绕过类型系统。甚至哈斯克尔也有unsafeCoerce。但此类设备应谨慎使用。弗兰兹·卡夫卡的角色格雷戈尔·萨姆萨在变身为一只巨大的虫子时打破了类型系统，我们都知道它的结局。

The only serious argument I hear against strong static type checking is that it might eliminate some programs that are semantically correct. In practice, this happens extremely rarely and, in any case, every language provides some kind of a backdoor to bypass the type system when that’s really necessary. Even Haskell has unsafeCoerce. But such devices should by used judiciously. Franz Kafka’s character, Gregor Samsa, breaks the type system when he metamorphoses into a giant bug, and we all know how it ends.

我经常听到的另一个论点是，处理类型给程序员带来了太多负担。在我自己用 C++ 编写了一些迭代器声明之后，我可能会同情这种情绪，除了有一种称为类型推断的技术，它可以让编译器从使用它们的上下文中推断出大多数类型。在 C++ 中，您现在可以声明变量auto并让编译器确定其类型。

Another argument I hear a lot is that dealing with types imposes too much burden on the programmer. I could sympathize with this sentiment after having to write a few declarations of iterators in C++ myself, except that there is a technology called type inference that lets the compiler deduce most of the types from the context in which they are used. In C++, you can now declare a variable auto and let the compiler figure out its type.

在 Haskell 中，除了极少数情况外，类型注释完全是可选的。程序员无论如何都倾向于使用它们，因为它们可以告诉我们很多关于代码的语义，并且它们使编译错误更容易理解。通过设计类型来启动项目是 Haskell 中的常见做法。后来，类型注释驱动实现并成为编译器强制注释。

In Haskell, except on rare occasions, type annotations are purely optional. Programmers tend to use them anyway, because they can tell a lot about the semantics of code, and they make compilation errors easier to understand. It’s a common practice in Haskell to start a project by designing the types. Later, type annotations drive the implementation and become compiler-enforced comments.

强静态类型经常被用作不测试代码的借口。有时你可能会听到 Haskell 程序员说：“如果它能编译，它一定是正确的。” 当然，不能保证类型正确的程序在产生正确输出的意义上是正确的。这种漫不经心的态度的结果是，在多项研究中，Haskell 在代码质量方面并没有像人们预期的那样遥遥领先。看来，在商业环境中，修复错误的压力只施加到一定的质量水平，这与软件开发的经济性和最终用户的容忍度密切相关，而与软件开发的成本无关。编程语言或方法。更好的标准是衡量有多少项目落后于计划或交付的功能大幅减少。

Strong static typing is often used as an excuse for not testing the code. You may sometimes hear Haskell programmers saying, “If it compiles, it must be correct.” Of course, there is no guarantee that a type-correct program is correct in the sense of producing the right ouput. The result of this cavalier attitude is that in several studies Haskell didn’t come as strongly ahead of the pack in code quality as one would expect. It seems that, in the commercial setting, the pressure to fix bugs is applied only up to a certain quality level, which has everything to do with the economics of software development and the tolerance of the end user, and very little to do with the programming language or methodology. A better criterion would be to measure how many projects fall behind schedule or are delivered with drastically reduced functionality.

至于单元测试可以取代强类型的论点，请考虑强类型语言中常见的重构实践：更改特定函数的参数类型。在强类型语言中，修改该函数的声明然后修复所有构建中断就足够了。在弱类型语言中，函数现在需要不同数据的事实无法传播到调用站点。单元测试可能会发现一些不匹配的情况，但测试几乎总是一个概率性过程，而不是一个确定性过程。测试并不能很好地替代证据。

As for the argument that unit testing can replace strong typing, consider the common refactoring practice in strongly typed languages: changing the type of an argument of a particular function. In a strongly typed language, it’s enough to modify the declaration of that function and then fix all the build breaks. In a weakly typed language, the fact that a function now expects different data cannot be propagated to call sites. Unit testing may catch some of the mismatches, but testing is almost always a probabilistic rather than a deterministic process. Testing is a poor substitute for proof.

3.3什么是类型？

3.3 What Are Types?

对于类型最简单的直觉是它们是值的集合。类型（请记住，具体类型在 Haskell 中以大写字母开头）是和Bool的二元素集。类型是所有 Unicode 字符的集合，例如或。TrueFalseChar'a''ą'

The simplest intuition for types is that they are sets of values. The type Bool (remember, concrete types start with a capital letter in Haskell) is a two-element set of True and False. Type Char is a set of all Unicode characters like 'a' or 'ą'.

集合可以是有限的或无限的。的类型String是 的列表的同义词Char，是无限集的一个示例。

Sets can be finite or infinite. The type of String, which is a synonym for a list of Char, is an example of an infinite set.

当我们声明x为Integer：

When we declare x to be an Integer:

x :: Integer

x :: Integer

我们说它是整数集合的一个元素。Integer在Haskell中是一个无限集，它可以用来做任意精度的算术。还有一个Int与机器类型对应的有限集，就像 C++ 一样int。

we are saying that it’s an element of the set of integers. Integer in Haskell is an infinite set, and it can be used to do arbitrary precision arithmetic. There is also a finite-set Int that corresponds to machine type, just like the C++ int.

有一些微妙之处使得类型和集合的识别变得棘手。涉及循环定义的多态函数存在问题，并且不能拥有所有集合的集合；但正如我所承诺的，我不会坚持数学。最棒的是有一类集合，称为Set，我们将直接使用它。在Set中，对象是集合，态射（箭头）是函数。

There are some subtleties that make this identification of types and sets tricky. There are problems with polymorphic functions that involve circular definitions, and with the fact that you can’t have a set of all sets; but as I promised, I won’t be a stickler for math. The great thing is that there is a category of sets, which is called Set, and we’ll just work with it. In Set, objects are sets and morphisms (arrows) are functions.

集合是一个非常特殊的范畴，因为我们实际上可以窥视它的对象内部并从中获得很多直觉。例如，我们知道空集没有元素。我们知道存在特殊的单元素集。我们知道函数将一个集合的元素映射到另一集合的元素。它们可以将两个元素映射到一个元素，但不能将一个元素映射到两个元素。我们知道恒等函数将集合中的每个元素映射到其自身，依此类推。计划是逐渐忘记所有这些信息，并用纯粹的分类术语（即对象​​和箭头）表达所有这些概念。

Set is a very special category, because we can actually peek inside its objects and get a lot of intuitions from doing that. For instance, we know that an empty set has no elements. We know that there are special one-element sets. We know that functions map elements of one set to elements of another set. They can map two elements to one, but not one element to two. We know that an identity function maps each element of a set to itself, and so on. The plan is to gradually forget all this information and instead express all those notions in purely categorical terms, that is in terms of objects and arrows.

在理想的世界中，我们只会说 Haskell 类型是集合，Haskell 函数是集合之间的数学函数。只有一个小问题：数学函数不执行任何代码——它只知道答案。Haskell 函数必须计算答案。如果可以在有限数量的步骤中获得答案，那么这不是问题——无论这个数字有多大。但有些计算涉及递归，并且这些计算可能永远不会终止。我们不能仅仅禁止 Haskell 中的非终止函数，因为终止函数和非终止函数之间的区别是不可判定的——这就是著名的停机问题。这就是为什么计算机科学家想出了一个绝妙的主意，或者一个重大的黑客，根据你的观点，将每种类型扩展一个更特殊的值，称为底部，并用 或 Unicode ⊥表示_|_。这个“值”对应于一个非终止的计算。所以函数声明为：

In the ideal world we would just say that Haskell types are sets and Haskell functions are mathematical functions between sets. There is just one little problem: A mathematical function does not execute any code — it just knows the answer. A Haskell function has to calculate the answer. It’s not a problem if the answer can be obtained in a finite number of steps — however big that number might be. But there are some calculations that involve recursion, and those might never terminate. We can’t just ban non-terminating functions from Haskell because distinguishing between terminating and non-terminating functions is undecidable — the famous halting problem. That’s why computer scientists came up with a brilliant idea, or a major hack, depending on your point of view, to extend every type by one more special value called the bottom and denoted by _|_, or Unicode ⊥. This “value” corresponds to a non-terminating computation. So a function declared as:

f :: Bool -> Bool

f :: Bool -> Bool

可能会返回True, False, 或_|_; 后者意味着它永远不会终止。

may return True, False, or _|_; the latter meaning that it would never terminate.

有趣的是，一旦接受底部作为类型系统的一部分，就可以方便地将每个运行时错误视为底部，甚至允许函数显式返回底部。后者通常使用表达式 完成undefined，如下所示：

Interestingly, once you accept the bottom as part of the type system, it is convenient to treat every runtime error as a bottom, and even allow functions to return the bottom explicitly. The latter is usually done using the expression undefined, as in:

f :: Bool -> Bool
f x = undefined

f :: Bool -> Bool
f x = undefined

此定义类型检查，因为undefined计算结果为 Bottom，它是任何类型的成员，包括Bool. 你甚至可以写：

This definition type checks because undefined evaluates to bottom, which is a member of any type, including Bool. You can even write:

f :: Bool -> Bool
f = undefined

f :: Bool -> Bool
f = undefined

（不带x）因为底部也是成员类型Bool->Bool。

(without the x) because the bottom is also a member of the type Bool->Bool.

可能返回底部的函数称为部分函数，​​而不是全部函数，后者为每个可能的参数返回有效结果。

Functions that may return bottom are called partial, as opposed to total functions, which return valid results for every possible argument.

由于底部，您将看到 Haskell 类型和函数的范畴被称为Hask而不是Set。从理论上来看，这就是永无休止的复杂性的根源，所以此时我将使用我的屠刀，终止这条推理路线。从实用的角度来看，忽略非终止函数和底部是可以的，并将Hask视为真正的Set（请参阅最后的参考书目）。

Because of the bottom, you’ll see the category of Haskell types and functions referred to as Hask rather than Set. From the theoretical point of view, this is the source of never-ending complications, so at this point I will use my butcher’s knife and terminate this line of reasoning. From the pragmatic point of view, it’s okay to ignore non-terminating functions and bottoms, and treat Hask as bona fide Set (see Bibliography at the end).

3.4为什么我们需要一个数学模型？

3.4 Why Do We Need a Mathematical Model?

作为一名程序员，您非常熟悉编程语言的语法和语法。语言的这些方面通常在语言规范的开头使用正式符号进行描述。但语言的含义或语义更难描述；它需要更多的页数，很少不够正式，而且几乎永远不会完整。因此，语言律师之间永无休止的讨论，以及致力于解释语言标准细节的书籍的整个家庭手工业。

As a programmer you are intimately familiar with the syntax and grammar of your programming language. These aspects of the language are usually described using formal notation at the very beginning of the language spec. But the meaning, or semantics, of the language is much harder to describe; it takes many more pages, is rarely formal enough, and almost never complete. Hence the never ending discussions among language lawyers, and a whole cottage industry of books dedicated to the exegesis of the finer points of language standards.

有一些正式的工具可以用来描述语言的语义，但由于其复杂性，它们大多用于简化的学术语言，而不是现实生活中的编程庞然大物。一种称为操作语义的工具描述了程序执行的机制。它定义了一个形式化的理想化解释器。工业语言（例如 C++）的语义通常使用非正式的操作推理来描述，通常用“抽象机器”来描述。

There are formal tools for describing the semantics of a language but, because of their complexity, they are mostly used with simplified academic languages, not real-life programming behemoths. One such tool called operational semantics describes the mechanics of program execution. It defines a formalized idealized interpreter. The semantics of industrial languages, such as C++, is usually described using informal operational reasoning, often in terms of an “abstract machine.”

问题在于，很难使用操作语义来证明程序的相关内容。要显示程序的属性，您本质上必须通过理想化的解释器“运行它”。

The problem is that it’s very hard to prove things about programs using operational semantics. To show a property of a program you essentially have to “run it” through the idealized interpreter.

程序员从不执行正式的正确性证明并不重要。我们总是“认为”我们编写了正确的程序。没有人坐在键盘前说：“哦，我只需输入几行代码，看看会发生什么。” 我们认为我们编写的代码将执行某些操作，从而产生所需的结果。当事实并非如此时，我们通常会感到非常惊讶。这意味着我们对编写的程序进行推理，并且通常是通过在头脑中运行解释器来实现的。跟踪所有变量确实很难。计算机擅长运行程序，而人类则不然！如果是的话，我们就不需要计算机了。

It doesn’t matter that programmers never perform formal proofs of correctness. We always “think” that we write correct programs. Nobody sits at the keyboard saying, “Oh, I’ll just throw a few lines of code and see what happens.” We think that the code we write will perform certain actions that will produce desired results. We are usually quite surprised when it doesn’t. That means we do reason about programs we write, and we usually do it by running an interpreter in our heads. It’s just really hard to keep track of all the variables. Computers are good at running programs — humans are not! If we were, we wouldn’t need computers.

但还有一个替代方案。它称为指称语义，它基于数学。在指称语义中，每个编程结构都被赋予了其数学解释。这样，如果你想证明一个程序的属性，你只需证明一个数学定理即可。你可能认为定理证明很难，但事实是，我们人类几千年来一直在建立数学方法，因此有大量积累的知识可供利用。此外，与专业数学家证明的定理相比，我们在编程中遇到的问题通常非常简单，甚至微不足道。

But there is an alternative. It’s called denotational semantics and it’s based on math. In denotational semantics every programing construct is given its mathematical interpretation. With that, if you want to prove a property of a program, you just prove a mathematical theorem. You might think that theorem proving is hard, but the fact is that we humans have been building up mathematical methods for thousands of years, so there is a wealth of accumulated knowledge to tap into. Also, as compared to the kind of theorems that professional mathematicians prove, the problems that we encounter in programming are usually quite simple, if not trivial.

考虑 Haskell 中阶乘函数的定义，这是一种非常适合指称语义的语言：

Consider the definition of a factorial function in Haskell, which is a language quite amenable to denotational semantics:

fact n = product [1..n]

fact n = product [1..n]

表达式[1..n]是从 1 到 n 的整数列表。该函数product将列表中的所有元素相乘。这就像数学课本中阶乘的定义一样。与 C 比较：

The expression [1..n] is a list of integers from 1 to n. The function product multiplies all elements of a list. That’s just like a definition of factorial taken from a math text. Compare this with C:

int fact(int n)
{
    int i;
    int result = 1;
    for (i = 2; i <= n; ++i)
        result *= i;
    return result;
}

int fact(int n)
{
    int i;
    int result = 1;
    for (i = 2; i <= n; ++i)
        result *= i;
    return result;
}

需要我多说？

Need I say more?

好吧，我第一个承认这是一个廉价的镜头！阶乘函数具有明显的数学含义。精明的读者可能会问：从键盘读取字符或通过网络发送数据包的数学模型是什么？在很长一段时间里，这都是一个尴尬的问题，导致了相当复杂的解释。似乎指称语义并不最适合大量重要任务，这些任务对于编写有用的程序至关重要，并且可以通过操作语义轻松解决。突破来自范畴论。Eugenio Moggi 发现计算效果可以映射到单子。事实证明，这是一个重要的观察结果，它不仅给指称语义带来了新的生命，使纯函数式程序更加可用，而且还为传统编程带来了新的曙光。稍后，当我们开发更多分类工具时，我将讨论单子。

Okay, I’ll be the first to admit that this was a cheap shot! A factorial function has an obvious mathematical denotation. An astute reader might ask: What’s the mathematical model for reading a character from the keyboard or sending a packet across the network? For the longest time that would have been an awkward question leading to a rather convoluted explanation. It seemed like denotational semantics wasn’t the best fit for a considerable number of important tasks that were essential for writing useful programs, and which could be easily tackled by operational semantics. The breakthrough came from category theory. Eugenio Moggi discovered that computational effect can be mapped to monads. This turned out to be an important observation that not only gave denotational semantics a new lease on life and made pure functional programs more usable, but also shed new light on traditional programming. I’ll talk about monads later, when we develop more categorical tools.

拥有编程数学模型的重要优点之一是可以对软件的正确性进行正式证明。当您编写消费者软件时，这似乎并不那么重要，但在某些编程领域，失败的代价可能会很高，或者人的生命受到威胁。但即使在为医疗系统编写 Web 应用程序时，您也可能会欣赏 Haskell 标准库中的函数和算法带有正确性证明的想法。

One of the important advantages of having a mathematical model for programming is that it’s possible to perform formal proofs of correctness of software. This might not seem so important when you’re writing consumer software, but there are areas of programming where the price of failure may be exorbitant, or where human life is at stake. But even when writing web applications for the health system, you may appreciate the thought that functions and algorithms from the Haskell standard library come with proofs of correctness.

3.5纯函数和脏函数

3.5 Pure and Dirty Functions

我们在 C++ 或任何其他命令式语言中称为函数的东西与数学家称为函数的东西不同。数学函数只是值到值的映射。

The things we call functions in C++ or any other imperative language, are not the same things mathematicians call functions. A mathematical function is just a mapping of values to values.

我们可以用编程语言实现一个数学函数：这样的函数，给定输入值将计算输出值。生成数字平方的函数可能会将输入值乘以自身。每次调用它时都会执行此操作，并且每次使用相同的输入调用它时都保证产生相同的输出。数字的平方不随月相变化。

We can implement a mathematical function in a programming language: Such a function, given an input value will calculate the output value. A function to produce a square of a number will probably multiply the input value by itself. It will do it every time it’s called, and it’s guaranteed to produce the same output every time it’s called with the same input. The square of a number doesn’t change with the phases of the Moon.

此外，计算数字的平方不应该对为您的狗分配美味佳肴产生副作用。做到这一点的“函数”不能轻易地建模为数学函数。

Also, calculating the square of a number should not have a side effect of dispensing a tasty treat for your dog. A “function” that does that cannot be easily modelled as a mathematical function.

在编程语言中，在给定相同输入的情况下始终产生相同结果并且没有副作用的函数称为纯函数。在像 Haskell 这样的纯函数式语言中，所有函数都是纯函数。因此，更容易为这些语言赋予指称语义并使用范畴论对其进行建模。至于其他语言，总是可以将自己限制在一个纯子集，或者单独推理副作用。稍后我们将看到 monad 如何让我们仅使用纯函数来建模各种效果。因此，将自己限制在数学函数上确实不会造成任何损失。

In programming languages, functions that always produce the same result given the same input and have no side effects are called pure functions. In a pure functional language like Haskell all functions are pure. Because of that, it’s easier to give these languages denotational semantics and model them using category theory. As for other languages, it’s always possible to restrict yourself to a pure subset, or reason about side effects separately. Later we’ll see how monads let us model all kinds of effects using only pure functions. So we really don’t lose anything by restricting ourselves to mathematical functions.

3.6类型示例

3.6 Examples of Types

一旦您意识到类型是集合，您就可以想到一些相当奇特的类型。例如，空集对应的类型是什么？不，它不是 C++ void，尽管这种类型在 Haskell 中被调用Void。它是一种不包含任何值的类型。您可以定义一个接受 的函数Void，但您永远不能调用它。要调用它，您必须提供 type 的值Void，但实际上没有。至于这个函数可以返回什么，没有任何限制。它可以返回任何类型（尽管它永远不会，因为它无法被调用）。换句话说，它是一个返回类型是多态的函数。Haskellers 给它起了个名字：

Once you realize that types are sets, you can think of some rather exotic types. For instance, what’s the type corresponding to an empty set? No, it’s not C++ void, although this type is called Void in Haskell. It’s a type that’s not inhabited by any values. You can define a function that takes Void, but you can never call it. To call it, you would have to provide a value of the type Void, and there just aren’t any. As for what this function can return, there are no restrictions whatsoever. It can return any type (although it never will, because it can’t be called). In other words it’s a function that’s polymorphic in the return type. Haskellers have a name for it:

absurd :: Void -> a

absurd :: Void -> a

（记住，a是一个可以代表任何类型的类型变量。）这个名称并非巧合。从逻辑角度对类型和函数有更深入的解释，称为 Curry-Howard 同构。类型Void代表虚假，而函数的类型absurd对应于任何事物都源自虚假的陈述，如拉丁语格言“ex falso sequitur quodlibet”。

(Remember, a is a type variable that can stand for any type.) The name is not coincidental. There is deeper interpretation of types and functions in terms of logic called the Curry-Howard isomorphism. The type Void represents falsity, and the type of the function absurd corresponds to the statement that from falsity follows anything, as in the Latin adage “ex falso sequitur quodlibet.”

接下来是与单例集对应的类型。它是一种只有一个可能值的类型。这个值只是“是”。您可能不会立即认出它，但这就是 C++ void。考虑这种类型的函数。函数 fromvoid始终可以被调用。如果它是纯函数，它将始终返回相同的结果。这是此类函数的示例：

Next is the type that corresponds to a singleton set. It’s a type that has only one possible value. This value just “is.” You might not immediately recognise it as such, but that is the C++ void. Think of functions from and to this type. A function from void can always be called. If it’s a pure function, it will always return the same result. Here’s an example of such a function:

int f44() { return 44; }

int f44() { return 44; }

您可能会认为这个函数不接受“任何东西”，但正如我们刚刚看到的，一个不接受“任何东西”的函数永远不会被调用，因为没有值代表“什么也不做”。那么这个函数需要什么呢？从概念上讲，它需要一个虚拟值，该值只有一个实例，因此我们不必明确提及它。然而，在 Haskell 中，这个值有一个符号：一对空括号，()。因此，出于一个有趣的巧合（或者这是一个巧合？），对 void 函数的调用在 C++ 和 Haskell 中看起来是相同的。另外，由于 Haskell 喜欢简洁，因此()类型、构造函数以及与单例集相对应的唯一值使用相同的符号。这是 Haskell 中的这个函数：

You might think of this function as taking “nothing”, but as we’ve just seen, a function that takes “nothing” can never be called because there is no value representing “nothing.” So what does this function take? Conceptually, it takes a dummy value of which there is only one instance ever, so we don’t have to mention it explicitly. In Haskell, however, there is a symbol for this value: an empty pair of parentheses, (). So, by a funny coincidence (or is it a coincidence?), the call to a function of void looks the same in C++ and in Haskell. Also, because of the Haskell’s love of terseness, the same symbol () is used for the type, the constructor, and the only value corresponding to a singleton set. So here’s this function in Haskell:

f44 :: () -> Integer
f44 () = 44

f44 :: () -> Integer
f44 () = 44

第一行声明f44将 type ()，发音为“unit”，放入 type 中Integer。第二行f44通过模式匹配 unit 的唯一构造函数来定义，即()，并生成数字 44。您可以通过提供单位值 来调用此函数()：

The first line declares that f44 takes the type (), pronounced “unit,” into the type Integer. The second line defines f44 by pattern matching the only constructor for unit, namely (), and producing the number 44. You call this function by providing the unit value ():

f44 ()

f44 ()

请注意，unit 的每个函数都相当于从目标类型中选取单个元素（此处选取 44 Integer）。事实上，您可以将其视为f44数字 44 的不同表示形式。这是一个示例，说明我们如何通过讨论函数（箭头）来替换对集合元素的明确提及。从单元到任何类型 A 的函数都与该集合 A 的元素一一对应。

Notice that every function of unit is equivalent to picking a single element from the target type (here, picking the Integer 44). In fact you could think of f44 as a different representation for the number 44. This is an example of how we can replace explicit mention of elements of a set by talking about functions (arrows) instead. Functions from unit to any type A are in one-to-one correspondence with the elements of that set A.

void具有返回类型的函数，或者在 Haskell 中，具有单位返回类型的函数又如何呢？在 C++ 中，此类函数用于产生副作用，但我们知道这些函数并不是数学意义上的真正函数。返回单位的纯函数不执行任何操作：它丢弃其参数。

What about functions with the void return type, or, in Haskell, with the unit return type? In C++ such functions are used for side effects, but we know that these are not real functions in the mathematical sense of the word. A pure function that returns unit does nothing: it discards its argument.

从数学上讲，从集合 A 到单例集的函数将 A 的每个元素映射到该单例集的单个元素。对于每一个 A 都只有一个这样的函数。这是这个函数Integer：

Mathematically, a function from a set A to a singleton set maps every element of A to the single element of that singleton set. For every A there is exactly one such function. Here’s this function for Integer:

fInt :: Integer -> ()
fInt x = ()

fInt :: Integer -> ()
fInt x = ()

你给它任何整数，它就会返回一个单位。本着简洁的精神，Haskell 允许您使用通配符模式（下划线）来表示被丢弃的参数。这样您就不必为它发明一个名称。所以上式可以改写为：

You give it any integer, and it gives you back a unit. In the spirit of terseness, Haskell lets you use the wildcard pattern, the underscore, for an argument that is discarded. This way you don’t have to invent a name for it. So the above can be rewritten as:

fInt :: Integer -> ()
fInt _ = ()

fInt :: Integer -> ()
fInt _ = ()

请注意，该函数的实现不仅不依赖于传递给它的值，而且甚至不依赖于参数的类型。

Notice that the implementation of this function not only doesn’t depend on the value passed to it, but it doesn’t even depend on the type of the argument.

对于任何类型都可以使用相同公式实现的函数称为参数多态。您可以使用类型参数而不是具体类型，通过一个方程来实现一整套此类函数。我们应该如何称呼从任意类型到单元类型的多态函数？当然我们会称它为unit：

Functions that can be implemented with the same formula for any type are called parametrically polymorphic. You can implement a whole family of such functions with one equation using a type parameter instead of a concrete type. What should we call a polymorphic function from any type to unit type? Of course we’ll call it unit:

unit :: a -> ()
unit _ = ()

unit :: a -> ()
unit _ = ()

在 C++ 中，您可以将此函数编写为：

In C++ you would write this function as:

template
void unit(T) {}

template
void unit(T) {}

类型分类中的下一个是二元素集。在 C++ 中，它被称为bool，而在 Haskell 中，可以预见，它被称为Bool. 不同之处在于，在 C++ 中bool是内置类型，而在 Haskell 中可以定义如下：

Next in the typology of types is a two-element set. In C++ it’s called bool and in Haskell, predictably, Bool. The difference is that in C++ bool is a built-in type, whereas in Haskell it can be defined as follows:

data Bool = True | False

data Bool = True | False

（阅读该定义的方式是Bool或True。False）原则上，我们还应该能够在 C++ 中将布尔类型定义为枚举：

(The way to read this definition is that Bool is either True or False.) In principle, one should also be able to define a Boolean type in C++ as an enumeration:

enum bool {
    true,
    false
};

enum bool {
    true,
    false
};

但C++enum秘密地是一个整数。可以使用C++11 “ enum class” 来代替，但随后您必须使用类名来限定其值，如 和 中bool::true，bool::false更不用说必须在使用它的每个文件中包含适当的标头。

but C++ enum is secretly an integer. The C++11 “enum class” could have been used instead, but then you would have to qualify its values with the class name, as in bool::true and bool::false, not to mention having to include the appropriate header in every file that uses it.

纯函数Bool只需从目标类型中选取两个值，一个对应于True，另一个对应于False。

Pure functions from Bool just pick two values from the target type, one corresponding to True and another to False.

函数 toBool称为谓词。例如，Haskell 库Data.Char充满了像isAlphaor之类的谓词isDigit。在 C++ 中，有一个类似的库，其中定义了isalpha和isdigit，但它们返回一个int而不是布尔值。实际谓词在 中定义，并具有、等std::ctype形式。ctype::is(alpha, c)ctype::is(digit, c)

Functions to Bool are called predicates. For instance, the Haskell library Data.Char is full of predicates like isAlpha or isDigit. In C++ there is a similar library that defines, among others, isalpha and isdigit, but these return an int rather than a Boolean. The actual predicates are defined in std::ctype and have the form ctype::is(alpha, c), ctype::is(digit, c), etc.

3.7挑战

3.7 Challenges

1. memoize用您喜欢的语言定义一个高阶函数（或函数对象） 。该函数采用纯函数f作为参数，并返回一个行为几乎与 完全相同的函数f，不同之处在于它只为每个参数调用一次原始函数，在内部存储结果，随后每次使用相同的值调用时都返回此存储的结果争论。您可以通过观察其性能来区分记忆的函数和原始函数。例如，尝试记住一个需要很长时间才能计算的函数。第一次调用它时，您必须等待结果，但在后续调用中，使用相同的参数，您应该立即获得结果。
2. Define a higher-order function (or a function object) memoize in your favorite language. This function takes a pure function f as an argument and returns a function that behaves almost exactly like f, except that it only calls the original function once for every argument, stores the result internally, and subsequently returns this stored result every time it’s called with the same argument. You can tell the memoized function from the original by watching its performance. For instance, try to memoize a function that takes a long time to evaluate. You’ll have to wait for the result the first time you call it, but on subsequent calls, with the same argument, you should get the result immediately.
3. 尝试记住标准库中通常用于生成随机数的函数。有效吗？
4. Try to memoize a function from your standard library that you normally use to produce random numbers. Does it work?
5. 大多数随机数生成器都可以使用种子进行初始化。实现一个函数，该函数接受种子，使用该种子调用随机数生成器，然后返回结果。记住该函数。有效吗？
6. Most random number generators can be initialized with a seed. Implement a function that takes a seed, calls the random number generator with that seed, and returns the result. Memoize that function. Does it work?
7. 以下哪些 C++ 函数是纯函数？尝试记住它们并观察多次调用它们时会发生什么：记住和不记住。
   1. 文本示例中的阶乘函数。

   2. std::getchar()

   3. bool f()
      { 
          std::cout << "Hello!" << std::endl;
          return true; 
      }

   4. int f(int x)
      {
          static int y = 0;
          y += x;
          return y;
      }

8. Which of these C++ functions are pure? Try to memoize them and observe what happens when you call them multiple times: memoized and not.
   1. The factorial function from the example in the text.

   2. std::getchar()

   3. bool f()
      { 
          std::cout << "Hello!" << std::endl;
          return true; 
      }

   4. int f(int x)
      {
          static int y = 0;
          y += x;
          return y;
      }

9. Bool从到共有多少种不同的函数Bool？你能全部实现吗？
10. How many different functions are there from Bool to Bool? Can you implement them all?
11. 绘制一个范畴的图片，其唯一对象是类型Void、()（单位）和Bool；箭头对应于这些类型之间所有可能的功能。用函数名称标记箭头。
12. Draw a picture of a category whose only objects are the types Void, () (unit), and Bool; with arrows corresponding to all possible functions between these types. Label the arrows with the names of the functions.

3.8参考书目

3.8 Bibliography

1. 尼尔斯·安德斯·丹尼尔森、约翰·休斯、帕特里克·詹森、杰里米·吉本斯，《快速而宽松的推理在道德上是正确的》。本文为在大多数情况下忽略底部提供了理由。
2. Nils Anders Danielsson, John Hughes, Patrik Jansson, Jeremy Gibbons, Fast and Loose Reasoning is Morally Correct. This paper provides justification for ignoring bottoms in most contexts.

4.1无对象

4.1 No Objects

最平凡的范畴是零个对象，因此零态射的范畴。它本身是一个非常悲伤的范畴，但在其他范畴的背景下，例如在所有范畴的范畴中（是的，有一个），它可能很重要。如果您认为空集有意义，那么为什么不是空范畴呢？

The most trivial category is one with zero objects and, consequently, zero morphisms. It’s a very sad category by itself, but it may be important in the context of other categories, for instance, in the category of all categories (yes, there is one). If you think that an empty set makes sense, then why not an empty category?

4.2简单图

4.2 Simple Graphs

您只需通过用箭头连接对象即可构建范畴。您可以想象从任何有向图开始，只需添加更多箭头即可将其变成一个范畴。首先，在每个节点添加一个恒等箭头。然后，对于任意两个箭头，其中一个箭头的结尾与另一个箭头的开头重合（换句话说，任意两个可组合箭头），添加一个新箭头作为它们的组合。每次添加新箭头时，您还必须考虑它与任何其他箭头（单位箭头除外）及其本身的组合。通常你最终会得到无限多个箭头，但这没关系。

You can build categories just by connecting objects with arrows. You can imagine starting with any directed graph and making it into a category by simply adding more arrows. First, add an identity arrow at each node. Then, for any two arrows such that the end of one coincides with the beginning of the other (in other words, any two composable arrows), add a new arrow to serve as their composition. Every time you add a new arrow, you have to also consider its composition with any other arrow (except for the identity arrows) and itself. You usually end up with infinitely many arrows, but that’s okay.

查看此过程的另一种方式是，您正在创建一个范畴，该范畴为图中的每个节点都有一个对象，以及作为态射的所有可能的可组合图边链。（您甚至可以将恒等态射视为长度为零的链的特殊情况。）

Another way of looking at this process is that you’re creating a category, which has an object for every node in the graph, and all possible chains of composable graph edges as morphisms. (You may even consider identity morphisms as special cases of chains of length zero.)

这样的范畴称为由给定图生成的自由范畴。这是自由构造的一个示例，即通过用最少数量的项扩展来完成给定结构以满足其定律（此处为范畴定律）的过程。将来我们会看到更多这样的例子。

Such a category is called a free category generated by a given graph. It’s an example of a free construction, a process of completing a given structure by extending it with a minimum number of items to satisfy its laws (here, the laws of a category). We’ll see more examples of it in the future.

4.3订单

4.3 Orders

现在我们来看看完全不同的东西！态射是对象之间的关系的范畴：小于或等于的关系。让我们检查一下它是否确实是一个范畴。我们有恒等态射吗？每个对象都小于或等于自身：检查！我们有组合吗？如果 a <= b 且 b <= c 则 a <= c：检查！组合是否具有结合性？查看！具有这样关系的集合称为前序，因此前序确实是一个范畴。

And now for something completely different! A category where a morphism is a relation between objects: the relation of being less than or equal. Let’s check if it indeed is a category. Do we have identity morphisms? Every object is less than or equal to itself: check! Do we have composition? If a <= b and b <= c then a <= c: check! Is composition associative? Check! A set with a relation like this is called a preorder, so a preorder is indeed a category.

您还可以有一个更强的关系，它满足一个附加条件，即如果 a <= b 且 b <= a，则 a 必须与 b 相同。这就是所谓的偏序。

You can also have a stronger relation, that satisfies an additional condition that, if a <= b and b <= a then a must be the same as b. That’s called a partial order.

最后，您可以强加一个条件，即任何两个对象都以某种方式相互关联；这给了你一个线性顺序或全序。

Finally, you can impose the condition that any two objects are in a relation with each other, one way or another; and that gives you a linear order or total order.

让我们将这些有序集描述为范畴。前序是一个范畴，其中从任何对象 a 到任何对象 b 至多有一个态射。这种范畴的另一个名称是“薄”。预购是一个很薄弱的范畴。

Let’s characterize these ordered sets as categories. A preorder is a category where there is at most one morphism going from any object a to any object b. Another name for such a category is “thin.” A preorder is a thin category.

范畴 C 中从对象 a 到对象 b 的态射集称为hom 集，写为 C(a, b)（有时也写为 Hom _C (a, b)）。因此，预购中的每个 hom-set 要么是空的，要么是单例的。这包括 hom 集 C(a, a)，即从 a 到 a 的态射集，它必须是单例，仅包含任何前序中的恒等式。但是，您可以预订周期。部分顺序禁止循环。

A set of morphisms from object a to object b in a category C is called a hom-set and is written as C(a, b) (or, sometimes, Hom_C(a, b)). So every hom-set in a preorder is either empty or a singleton. That includes the hom-set C(a, a), the set of morphisms from a to a, which must be a singleton, containing only the identity, in any preorder. You may, however, have cycles in a preorder. Cycles are forbidden in a partial order.

由于排序，能够识别预序、部分序和全序非常重要。排序算法，例如快速排序、冒泡排序、合并排序等，只能在总订单上正确工作。可以使用拓扑排序来对偏序进行排序。

It’s very important to be able to recognize preorders, partial orders, and total orders because of sorting. Sorting algorithms, such as quicksort, bubble sort, merge sort, etc., can only work correctly on total orders. Partial orders can be sorted using topological sort.

4.4 幺半群作为集合

4.4 Monoid as Set

Monoid 是一个简单得令人尴尬但强大得惊人的概念。这是基本算术背后的概念：加法和乘法都形成一个幺半群。幺半群在编程中无处不在。它们以字符串、列表、可折叠数据结构、并发编程中的 future、函数反应式编程中的事件等形式出现。

Monoid is an embarrassingly simple but amazingly powerful concept. It’s the concept behind basic arithmetics: Both addition and multiplication form a monoid. Monoids are ubiquitous in programming. They show up as strings, lists, foldable data structures, futures in concurrent programming, events in functional reactive programming, and so on.

传统上，幺半群被定义为具有二元运算的集合。此操作所需的只是它是关联的，并且有一个特殊元素的行为类似于它的一个单元。

Traditionally, a monoid is defined as a set with a binary operation. All that’s required from this operation is that it’s associative, and that there is one special element that behaves like a unit with respect to it.

例如，带有零的自然数在加法下形成幺半群。结合性意味着：

For instance, natural numbers with zero form a monoid under addition. Associativity means that:

(a + b) + c = a + (b + c)

(a + b) + c = a + (b + c)

（换句话说，我们在添加数字时可以跳过括号。）

(In other words, we can skip parentheses when adding numbers.)

中性元素为零，因为：

The neutral element is zero, because:

0 + a = a

0 + a = a

和

and

a + 0 = a

a + 0 = a

第二个方程是多余的，因为加法是可交换的 (a + b = b + a)，但交换性不是幺半群定义的一部分。例如，字符串连接是不可交换的，但它形成了一个幺半群。顺便说一下，字符串连接的中性元素是一个空字符串，它可以附加到字符串的任一侧而不改变它。

The second equation is redundant, because addition is commutative (a + b = b + a), but commutativity is not part of the definition of a monoid. For instance, string concatenation is not commutative and yet it forms a monoid. The neutral element for string concatenation, by the way, is an empty string, which can be attached to either side of a string without changing it.

在 Haskell 中，我们可以为幺半群定义一个类型类——该类型有一个名为 的中性元素mempty和一个名为 的二元运算mappend：

In Haskell we can define a type class for monoids — a type for which there is a neutral element called mempty and a binary operation called mappend:

class Monoid m where
    mempty  :: m
    mappend :: m -> m -> m

class Monoid m where
    mempty  :: m
    mappend :: m -> m -> m

双参数函数的类型签名一m->m->m开始可能看起来很奇怪，但在我们讨论柯里化之后它就会变得非常有意义。您可以通过两种基本方式解释具有多个箭头的签名：作为多个参数的函数，最右边的类型是返回类型；或者作为一个参数（最左边的参数）的函数，返回一个函数。可以通过添加括号（这是多余的，因为箭头是右结合的）来强调后一种解释，如：m->(m->m)。我们稍后会回到这个解释。

The type signature for a two-argument function, m->m->m, might look strange at first, but it will make perfect sense after we talk about currying. You may interpret a signature with multiple arrows in two basic ways: as a function of multiple arguments, with the rightmost type being the return type; or as a function of one argument (the leftmost one), returning a function. The latter interpretation may be emphasized by adding parentheses (which are redundant, because the arrow is right-associative), as in: m->(m->m). We’ll come back to this interpretation in a moment.

请注意，在 Haskell 中，无法表达mempty和的幺半群属性（即中性且结合的mappend事实）。确保他们满意是程序员的责任。memptymappend

Notice that, in Haskell, there is no way to express the monoidal properties of mempty and mappend (i.e., the fact that mempty is neutral and that mappend is associative). It’s the responsibility of the programmer to make sure they are satisfied.

Haskell 类不像 C++ 类那样具有侵入性。当您定义新类型时，不必预先指定其类。您可以自由地拖延并稍后将给定类型声明为某个类的实例。作为一个例子，让我们通过提供andString的实现来声明自己是一个幺半群（事实上，这是在标准 Prelude 中为您完成的）：memptymappend

Haskell classes are not as intrusive as C++ classes. When you’re defining a new type, you don’t have to specify its class up front. You are free to procrastinate and declare a given type to be an instance of some class much later. As an example, let’s declare String to be a monoid by providing the implementation of mempty and mappend (this is, in fact, done for you in the standard Prelude):

instance Monoid String where
    mempty = ""
    mappend = (++)

instance Monoid String where
    mempty = ""
    mappend = (++)

在这里，我们重用了列表连接运算符(++)，因为 aString只是一个字符列表。

Here, we have reused the list concatenation operator (++), because a String is just a list of characters.

关于 Haskell 语法的一句话：任何中缀运算符都可以通过用括号括起来而变成双参数函数。给定两个字符串，您可以通过在它们之间插入来连接它们++：

A word about Haskell syntax: Any infix operator can be turned into a two-argument function by surrounding it with parentheses. Given two strings, you can concatenate them by inserting ++ between them:

"Hello " ++ "world!"

"Hello " ++ "world!"

或者将它们作为两个参数传递给括号(++)：

or by passing them as two arguments to the parenthesized (++):

(++) "Hello " "world!"

(++) "Hello " "world!"

请注意，函数的参数不是用逗号分隔或用括号括起来。（这可能是学习 Haskell 时最难适应的事情。）

Notice that arguments to a function are not separated by commas or surrounded by parentheses. (This is probably the hardest thing to get used to when learning Haskell.)

值得强调的是，Haskell 允许您表达函数的相等性，如下所示：

It’s worth emphasizing that Haskell lets you express equality of functions, as in:

mappend = (++)

mappend = (++)

从概念上讲，这与表达函数产生的值的相等性不同，如下所示：

Conceptually, this is different than expressing the equality of values produced by functions, as in:

mappend s1 s2 = (++) s1 s2

mappend s1 s2 = (++) s1 s2

前者转化为Hask范畴中的态射相等（或者Set，如果我们忽略底部，这是永无止境的计算的名称）。这样的方程不仅更简洁，而且通常可以推广到其他范畴。后者称为外延相等，它指出了这样一个事实：对于任何两个输入字符串，mappend和 的输出(++)都是相同的。由于参数的值有时称为点（如：f 在点 x 处的值），因此这称为逐点相等。不指定参数的函数相等被描述为point-free。（顺便说一句，无点方程通常涉及函数的组合，这些函数由点表示，因此这可能会让初学者有点困惑。）

The former translates into equality of morphisms in the category Hask (or Set, if we ignore bottoms, which is the name for never-ending calculations). Such equations are not only more succinct, but can often be generalized to other categories. The latter is called extensional equality, and states the fact that for any two input strings, the outputs of mappend and (++) are the same. Since the values of arguments are sometimes called points (as in: the value of f at point x), this is called point-wise equality. Function equality without specifying the arguments is described as point-free. (Incidentally, point-free equations often involve composition of functions, which is symbolized by a point, so this might be a little confusing to the beginner.)

在 C++ 中声明幺半群最接近的方法是使用（建议的）概念语法。

The closest one can get to declaring a monoid in C++ would be to use the (proposed) syntax for concepts.

template
  T mempty = delete;

template
  T mappend(T, T) = delete;

template
  concept bool Monoid = requires (M m) {
    { mempty } -> M;
    { mappend(m, m); } -> M;
  };

template
  T mempty = delete;

template
  T mappend(T, T) = delete;

template
  concept bool Monoid = requires (M m) {
    { mempty } -> M;
    { mappend(m, m); } -> M;
  };

第一个定义使用值模板（也已提议）。多态值是一个值族——每种类型都有不同的值。

The first definition uses a value template (also proposed). A polymorphic value is a family of values — a different value for every type.

该关键字delete意味着没有定义默认值：必须根据具体情况进行指定。同样，没有默认值mappend。

The keyword delete means that there is no default value defined: It will have to be specified on a case-by-case basis. Similarly, there is no default for mappend.

这个概念Monoid是一个谓词（因此是类型），用于测试给定类型和bool是否存在适当的定义。memptymappendM

The concept Monoid is a predicate (hence the bool type) that tests whether there exist appropriate definitions of mempty and mappend for a given type M.

Monoid 概念的实例化可以通过提供适当的特化和重载来完成：

An instantiation of the Monoid concept can be accomplished by providing appropriate specializations and overloads:

template<>
std::string mempty = {""};

std::string mappend(std::string s1, std::string s2) {
    return s1 + s2;
}

template<>
std::string mempty = {""};

std::string mappend(std::string s1, std::string s2) {
    return s1 + s2;
}

4.5 幺半群作为范畴

4.5 Monoid as Category

这是对集合元素的幺半群的“熟悉”定义。但正如你所知，在范畴论中，我们试图摆脱集合及其元素，而是谈论对象和态射。因此，让我们稍微改变一下我们的观点，将二元运算符的应用视为围绕集合“移动”或“移动”事物。

That was the “familiar” definition of the monoid in terms of elements of a set. But as you know, in category theory we try to get away from sets and their elements, and instead talk about objects and morphisms. So let’s change our perspective a bit and think of the application of the binary operator as “moving” or “shifting” things around the set.

例如，有每个自然数加5的运算。它将 0 映射到 5、1 到 6、2 到 7，依此类推。这是在自然数集上定义的函数。这很好：我们有一个函数和一个集合。一般来说，对于任何数字 n，都有一个将 n 加起来的函数——n 的“加法器”。

For instance, there is the operation of adding 5 to every natural number. It maps 0 to 5, 1 to 6, 2 to 7, and so on. That’s a function defined on the set of natural numbers. That’s good: we have a function and a set. In general, for any number n there is a function of adding n — the “adder” of n.

加法器是如何组成的？加5的函数与加7的函数的复合是加12的函数。因此加法器的复合可以等效于加法规则。这也很好：我们可以用函数组合代替加法。

How do adders compose? The composition of the function that adds 5 with the function that adds 7 is a function that adds 12. So the composition of adders can be made equivalent to the rules of addition. That’s good too: we can replace addition with function composition.

但是等等，还有更多：还有中性元素零的加法器。加零不会改变事物的位置，因此它是自然数集合中的恒等函数。

But wait, there’s more: There is also the adder for the neutral element, zero. Adding zero doesn’t move things around, so it’s the identity function in the set of natural numbers.

我不给你传统的加法规则，而是给你组合加法器的规则，而不会丢失任何信息。请注意，加法器的组合是结合的，因为函数的组合是结合的；我们有与恒等函数相对应的零加法器。

Instead of giving you the traditional rules of addition, I could as well give you the rules of composing adders, without any loss of information. Notice that the composition of adders is associative, because the composition of functions is associative; and we have the zero adder corresponding to the identity function.

精明的读者可能已经注意到，从整数到加法器的映射遵循mappendas类型签名的第二种解释m->(m->m)。它告诉我们将mappend幺半群集合的元素映射到作用于该集合的函数。

An astute reader might have noticed that the mapping from integers to adders follows from the second interpretation of the type signature of mappend as m->(m->m). It tells us that mappend maps an element of a monoid set to a function acting on that set.

现在我希望你忘记你正在处理一组自然数，而只是将其视为一个单一的对象，一个带有一堆态射的斑点——加法器。幺半群是单个对象范畴。事实上，monoid 这个名字来自希腊语mono，意思是单一。每个幺半群都可以被描述为具有一组遵循适当的组合规则的态射的单个对象范畴。

Now I want you to forget that you are dealing with the set of natural numbers and just think of it as a single object, a blob with a bunch of morphisms — the adders. A monoid is a single object category. In fact the name monoid comes from Greek mono, which means single. Every monoid can be described as a single object category with a set of morphisms that follow appropriate rules of composition.

字符串连接是一个有趣的例子，因为我们可以选择定义右追加器和左追加器（或者prependers，如果你愿意的话）。两个模型的成分表互为镜像相反。您可以轻松地说服自己，在“foo”之后附加“bar”相当于在“bar”之后添加“foo”。

String concatenation is an interesting case, because we have a choice of defining right appenders and left appenders (or prependers, if you will). The composition tables of the two models are a mirror reverse of each other. You can easily convince yourself that appending “bar” after “foo” corresponds to prepending “foo” after prepending “bar”.

您可能会问，是否每个分类幺半群（单对象范畴）都定义了一个唯一的带有二元运算符集合的幺半群。事实证明，我们总是可以从单个对象范畴中提取一个集合。这个集合是态射的集合——我们例子中的加法器。换句话说，我们有范畴 M 中单个对象 m 的 hom 集 M(m, m)。我们可以轻松地在这个集合中定义一个二元运算符：两个集合元素的幺半积就是对应于相应态射的组合。如果你给我 M(m, m) 中对应于f和的两个元素g，它们的乘积将对应于组合g∘f。组合始终存在，因为这些态射的源和目标是同一个对象。并且它是按照范畴规则关联的。恒等态射是该乘积的中性元素。所以我们总是可以从范畴幺半群中恢复集合幺半群。就所有意图和目的而言，它们都是一样的。

You might ask the question whether every categorical monoid — a one-object category — defines a unique set-with-binary-operator monoid. It turns out that we can always extract a set from a single-object category. This set is the set of morphisms — the adders in our example. In other words, we have the hom-set M(m, m) of the single object m in the category M. We can easily define a binary operator in this set: The monoidal product of two set-elements is the element corresponding to the composition of the corresponding morphisms. If you give me two elements of M(m, m) corresponding to f and g, their product will correspond to the composition g∘f. The composition always exists, because the source and the target for these morphisms are the same object. And it’s associative by the rules of category. The identity morphism is the neutral element of this product. So we can always recover a set monoid from a category monoid. For all intents and purposes they are one and the same.

幺半群 hom 集被视为态射和集合中的点

Monoid hom-set seen as morphisms and as points in a set

对于数学家来说，只有一个小问题需要注意：态射不必形成一个集合。在范畴的世界里，有比集合更大的东西。任意两个对象之间的态射形成集合的范畴称为局部小范畴。正如所承诺的，我基本上会忽略这些微妙之处，但我认为我应该提及它们以记录在案。

There is just one little nit for mathematicians to pick: morphisms don’t have to form a set. In the world of categories there are things larger than sets. A category in which morphisms between any two objects form a set is called locally small. As promised, I will be mostly ignoring such subtleties, but I thought I should mention them for the record.

范畴论中许多有趣的现象都源于这样一个事实：hom 集的元素既可以看作遵循组合规则的态射，也可以看作集合中的点。这里，M 中态射的复合转化为集合 M(m, m) 中的幺半群积。

A lot of interesting phenomena in category theory have their root in the fact that elements of a hom-set can be seen both as morphisms, which follow the rules of composition, and as points in a set. Here, composition of morphisms in M translates into monoidal product in the set M(m, m).

4.6致谢

4.6 Acknowledgments

我要感谢 Andrew Sutton 根据他和 Bjarne Stroustrup 的最新提案重写了我的 C++ 幺半群概念代码。

I’d like to thank Andrew Sutton for rewriting my C++ monoid concept code according to his and Bjarne Stroustrup’s latest proposal.

4.7挑战

4.7 Challenges

1. 生成一个免费范畴：
   1. 一张只有一个节点且没有边的图
   2. 具有一个节点和一个（有向）边的图（提示：该边可以与自身组成）
   3. 具有两个节点且它们之间有一个箭头的图
   4. 具有单个节点和 26 个标有字母的箭头的图：a、b、c … z。
2. Generate a free category from:
   1. A graph with one node and no edges
   2. A graph with one node and one (directed) edge (hint: this edge can be composed with itself)
   3. A graph with two nodes and a single arrow between them
   4. A graph with a single node and 26 arrows marked with the letters of the alphabet: a, b, c … z.
3. 这是什么样的订单？
   1. 具有包含关系的集合：如果 A 的每个元素也是 B 的元素，则 A 包含在 B 中。
   2. 具有以下子类型关系的 C++ 类型：如果指向 T1 的指针可以传递给需要指向 T2 的指针的函数而不触发编译错误，则 T1 是 T2 的子类型。
4. What kind of order is this?
   1. A set of sets with the inclusion relation: A is included in B if every element of A is also an element of B.
   2. C++ types with the following subtyping relation: T1 is a subtype of T2 if a pointer to T1 can be passed to a function that expects a pointer to T2 without triggering a compilation error.
5. &&考虑到 Bool 是两个值 True 和 False 的集合，表明它分别相对于运算符(AND) 和||(OR)形成两个（集合论）幺半群。
6. Considering that Bool is a set of two values True and False, show that it forms two (set-theoretical) monoids with respect to, respectively, operator && (AND) and || (OR).
7. 用 AND 运算符将 Bool 幺半群表示为范畴：列出态射及其组合规则。
8. Represent the Bool monoid with the AND operator as a category: List the morphisms and their rules of composition.
9. 将模 3 的加法表示为幺半群范畴。
10. Represent addition modulo 3 as a monoid category.

5.1日志的构成

5.1 Composition of Logs

您已经了解了如何将类型和纯函数建模为范畴。我还提到，有一种方法可以在范畴论中对副作用或非纯函数进行建模。让我们看一个这样的例子：记录或跟踪其执行的函数。在命令式语言中，可能会通过改变某些全局状态来实现，例如：

You’ve seen how to model types and pure functions as a category. I also mentioned that there is a way to model side effects, or non-pure functions, in category theory. Let’s have a look at one such example: functions that log or trace their execution. Something that, in an imperative language, would likely be implemented by mutating some global state, as in:

string logger;

bool negate(bool b) {
     logger += "Not so! ";
     return !b;
}

string logger;

bool negate(bool b) {
     logger += "Not so! ";
     return !b;
}

您知道这不是一个纯函数，因为它的记忆版本将无法生成日志。这个功能有副作用。

You know that this is not a pure function, because its memoized version would fail to produce a log. This function has side effects.

在现代编程中，我们尝试尽可能远离全局可变状态——即使只是因为并发的复杂性。而且你永远不会将这样的代码放入库中。

In modern programming, we try to stay away from global mutable state as much as possible — if only because of the complications of concurrency. And you would never put code like this in a library.

对我们来说幸运的是，可以使这个函数变得纯粹。您只需明确地传入和传出日志即可。让我们通过添加一个字符串参数，并将常规输出与包含更新日志的字符串配对来做到这一点：

Fortunately for us, it’s possible to make this function pure. You just have to pass the log explicitly, in and out. Let’s do that by adding a string argument, and pairing regular output with a string that contains the updated log:

pair<bool, string> negate(bool b, string logger) {
     return make_pair(!b, logger + "Not so! ");
}

pair<bool, string> negate(bool b, string logger) {
     return make_pair(!b, logger + "Not so! ");
}

这个函数是纯粹的，没有副作用，每次使用相同的参数调用时都会返回相同的对，并且如果需要的话可以记忆。但是，考虑到日志的累积性质，您必须记住可能导致给定调用的所有可能的历史记录。将会有一个单独的备忘录条目：

This function is pure, it has no side effects, it returns the same pair every time it’s called with the same arguments, and it can be memoized if necessary. However, considering the cumulative nature of the log, you’d have to memoize all possible histories that can lead to a given call. There would be a separate memo entry for:

negate(true, "It was the best of times. ");

negate(true, "It was the best of times. ");

和

and

negate(true, "It was the worst of times. ");

negate(true, "It was the worst of times. ");

等等。

and so on.

对于库函数来说它也不是一个很好的接口。调用者可以自由地忽略返回类型中的字符串，因此这并不是一个巨大的负担；但他们被迫传递一个字符串作为输入，这可能不方便。

It’s also not a very good interface for a library function. The callers are free to ignore the string in the return type, so that’s not a huge burden; but they are forced to pass a string as input, which might be inconvenient.

有没有一种方法可以减少干扰地做同样的事情？有没有办法分离关注点？在这个简单的示例中，该函数的主要目的negate是将一个布尔值转换为另一个布尔值。日志记录是次要的。当然，记录的消息是特定于该函数的，但将消息聚合到一个连续日志中的任务是一个单独的问题。我们仍然希望该函数生成一个字符串，但我们希望减轻它生成日志的负担。所以这是折衷的解决方案：

Is there a way to do the same thing less intrusively? Is there a way to separate concerns? In this simple example, the main purpose of the function negate is to turn one Boolean into another. The logging is secondary. Granted, the message that is logged is specific to the function, but the task of aggregating the messages into one continuous log is a separate concern. We still want the function to produce a string, but we’d like to unburden it from producing a log. So here’s the compromise solution:

pair<bool, string> negate(bool b) {
     return make_pair(!b, "Not so! ");
}

pair<bool, string> negate(bool b) {
     return make_pair(!b, "Not so! ");
}

这个想法是日志将在函数调用之间聚合。

The idea is that the log will be aggregated between function calls.

为了了解如何做到这一点，让我们切换到一个稍微更实际的示例。我们有一个从字符串到字符串的函数，可以将小写字符转换为大写字符：

To see how this can be done, let’s switch to a slightly more realistic example. We have one function from string to string that turns lower case characters to upper case:

string toUpper(string s) {
    string result;
    int (*toupperp)(int) = &toupper; // toupper is overloaded
    transform(begin(s), end(s), back_inserter(result), toupperp);
    return result;
}

string toUpper(string s) {
    string result;
    int (*toupperp)(int) = &toupper; // toupper is overloaded
    transform(begin(s), end(s), back_inserter(result), toupperp);
    return result;
}

另一个将字符串拆分为字符串向量，并在空白边界处将其打破：

and another that splits a string into a vector of strings, breaking it on whitespace boundaries:

vector<string> toWords(string s) {
    return words(s);
}

vector<string> toWords(string s) {
    return words(s);
}

实际工作是在辅助函数中完成的words：

The actual work is done in the auxiliary function words:

vector<string> words(string s) {
    vector<string> result{""};
    for (auto i = begin(s); i != end(s); ++i)
    {
        if (isspace(*i))
            result.push_back("");
        else
            result.back() += *i;
    }
    return result;
  }

vector<string> words(string s) {
    vector<string> result{""};
    for (auto i = begin(s); i != end(s); ++i)
    {
        if (isspace(*i))
            result.push_back("");
        else
            result.back() += *i;
    }
    return result;
  }

我们想要修改这些函数toUpper，toWords以便它们在常规返回值之上搭载消息字符串。

We want to modify the functions toUpper and toWords so that they piggyback a message string on top of their regular return values.

我们将“修饰”这些函数的返回值。让我们通过定义一个模板来以通用方式完成此操作，Writer该模板封装一对，其第一个组件是任意类型的值A，第二个组件是字符串：

We will “embellish” the return values of these functions. Let’s do it in a generic way by defining a template Writer that encapsulates a pair whose first component is a value of arbitrary type A and the second component is a string:

template<class A>
  using Writer = pair<A, string>;

template<class A>
  using Writer = pair<A, string>;

下面是修饰后的函数：

Here are the embellished functions:

Writer<string> toUpper(string s) {
  string result;
  int (*toupperp)(int) = &toupper;
  transform(begin(s), end(s), back_inserter(result), toupperp);
  return make_pair(result, "toUpper ");
}

Writer<vector<string>> toWords(string s) {
    return make_pair(words(s), "toWords ");
}

Writer<string> toUpper(string s) {
  string result;
  int (*toupperp)(int) = &toupper;
  transform(begin(s), end(s), back_inserter(result), toupperp);
  return make_pair(result, "toUpper ");
}

Writer<vector<string>> toWords(string s) {
    return make_pair(words(s), "toWords ");
}

我们希望将这两个函数组合成另一个修饰函数，该函数将字符串大写并将其拆分为单词，同时生成这些操作的日志。我们可以这样做：

We want to compose these two functions into another embellished function that uppercases a string and splits it into words, all the while producing a log of those actions. Here’s how we may do it:

Writer<vector<string>> process(string s) {
    auto p1 = toUpper(s);
    auto p2 = toWords(p1.first);
    return make_pair(p2.first, p1.second + p2.second);
}

Writer<vector<string>> process(string s) {
    auto p1 = toUpper(s);
    auto p2 = toWords(p1.first);
    return make_pair(p2.first, p1.second + p2.second);
}

我们已经实现了我们的目标：日志的聚合不再是各个函数的关注点。它们生成自己的消息，然后在外部将其连接成更大的日志。

We have accomplished our goal: The aggregation of the log is no longer the concern of the individual functions. They produce their own messages, which are then, externally, concatenated into a larger log.

现在想象一下以这种风格编写的整个程序。这是重复且容易出错的代码的噩梦。但我们是程序员。我们知道如何处理重复的代码：我们将其抽象！然而，这不是一般的抽象——我们必须抽象函数组合本身。但组合是范畴论的本质，所以在我们编写更多代码之前，让我们从范畴的角度来分析问题。

Now imagine a whole program written in this style. It’s a nightmare of repetitive, error-prone code. But we are programmers. We know how to deal with repetitive code: we abstract it! This is, however, not your run of the mill abstraction — we have to abstract function composition itself. But composition is the essence of category theory, so before we write more code, let’s analyze the problem from the categorical point of view.

5.2作家范畴

5.2 The Writer Category

修饰一堆函数的返回类型以搭载一些附加功能的想法被证明是非常富有成效的。我们将会看到更多这样的例子。起点是我们常规的类型和函数范畴。我们将把类型保留为对象，但将态射重新定义为修饰函数。

The idea of embellishing the return types of a bunch of functions in order to piggyback some additional functionality turns out to be very fruitful. We’ll see many more examples of it. The starting point is our regular category of types and functions. We’ll leave the types as objects, but redefine our morphisms to be the embellished functions.

例如，假设我们想要修饰isEven从int到 的函数bool。我们将其转换为由修饰函数表示的态射。重要的一点是，这个态射仍然被认为是对象int和之间的箭头bool，即使修饰函数返回一对：

For instance, suppose that we want to embellish the function isEven that goes from int to bool. We turn it into a morphism that is represented by an embellished function. The important point is that this morphism is still considered an arrow between the objects int and bool, even though the embellished function returns a pair:

pair<bool, string> isEven(int n) {
     return make_pair(n % 2 == 0, "isEven ");
}

pair<bool, string> isEven(int n) {
     return make_pair(n % 2 == 0, "isEven ");
}

根据范畴定律，我们应该能够将这个态射与另一个从对象bool到任何东西的态射组合起来。特别是，我们应该能够将它与我们之前的组合起来negate：

By the laws of a category, we should be able to compose this morphism with another morphism that goes from the object bool to whatever. In particular, we should be able to compose it with our earlier negate:

pair<bool, string> negate(bool b) {
     return make_pair(!b, "Not so! ");
}

pair<bool, string> negate(bool b) {
     return make_pair(!b, "Not so! ");
}

显然，由于输入/输出不匹配，我们不能像构造常规函数那样构造这两个态射。他们的组成应该看起来更像这样：

Obviously, we cannot compose these two morphisms the same way we compose regular functions, because of the input/output mismatch. Their composition should look more like this:

pair<bool, string> isOdd(int n) {
    pair<bool, string> p1 = isEven(n);
    pair<bool, string> p2 = negate(p1.first);
    return make_pair(p2.first, p1.second + p2.second);
}

pair<bool, string> isOdd(int n) {
    pair<bool, string> p1 = isEven(n);
    pair<bool, string> p2 = negate(p1.first);
    return make_pair(p2.first, p1.second + p2.second);
}

因此，这是我们正在构建的这个新范畴中两个态射的组合的秘诀：

So here’s the recipe for the composition of two morphisms in this new category we are constructing:

1. 执行第一个态射对应的修饰函数
2. Execute the embellished function corresponding to the first morphism
3. 提取结果对的第一个分量并将其传递给与第二个态射对应的修饰函数
4. Extract the first component of the result pair and pass it to the embellished function corresponding to the second morphism
5. 连接第一个结果的第二个组件（字符串）和第二个结果的第二个组件（字符串）
6. Concatenate the second component (the string) of of the first result and the second component (the string) of the second result
7. 返回一个新的对，将最终结果的第一个组成部分与连接的字符串相结合。
8. Return a new pair combining the first component of the final result with the concatenated string.

如果我们想将此组合抽象为 C++ 中的高阶函数，则必须使用由与范畴中的三个对象相对应的三种类型参数化的模板。它应该采用两个根据我们的规则可组合的修饰函数，并返回第三个修饰函数：

If we want to abstract this composition as a higher order function in C++, we have to use a template parameterized by three types corresponding to three objects in our category. It should take two embellished functions that are composable according to our rules, and return a third embellished function:

template<class A, class B, class C>
function<Writer<C>(A)> compose(function<Writer<B>(A)> m1, 
                               function<Writer<C>(B)> m2)
{
    return [m1, m2](A x) {
        auto p1 = m1(x);
        auto p2 = m2(p1.first);
        return make_pair(p2.first, p1.second + p2.second);
    };
}

template<class A, class B, class C>
function<Writer<C>(A)> compose(function<Writer<B>(A)> m1, 
                               function<Writer<C>(B)> m2)
{
    return [m1, m2](A x) {
        auto p1 = m1(x);
        auto p2 = m2(p1.first);
        return make_pair(p2.first, p1.second + p2.second);
    };
}

现在我们可以回到之前的示例并实现这个新模板的组合toUpper和使用：toWords

Now we can go back to our earlier example and implement the composition of toUpper and toWords using this new template:

Writer<vector<string>> process(string s) {
   return compose<string, string, vector<string>>(toUpper, toWords)(s);
}

Writer<vector<string>> process(string s) {
   return compose<string, string, vector<string>>(toUpper, toWords)(s);
}

将类型传递给模板仍然存在很多噪音compose。只要您有一个兼容 C++14 的编译器，支持带有返回类型推导的广义 lambda 函数，就可以避免这种情况（此代码归功于 Eric Niebler）：

There is still a lot of noise with the passing of types to the compose template. This can be avoided as long as you have a C++14-compliant compiler that supports generalized lambda functions with return type deduction (credit for this code goes to Eric Niebler):

auto const compose = [](auto m1, auto m2) {
    return [m1, m2](auto x) {
        auto p1 = m1(x);
        auto p2 = m2(p1.first);
        return make_pair(p2.first, p1.second + p2.second);
    };
};

auto const compose = [](auto m1, auto m2) {
    return [m1, m2](auto x) {
        auto p1 = m1(x);
        auto p2 = m2(p1.first);
        return make_pair(p2.first, p1.second + p2.second);
    };
};

在这个新定义中， 的实现process简化为：

In this new definition, the implementation of process simplifies to:

Writer<vector<string>> process(string s){
   return compose(toUpper, toWords)(s);
}

Writer<vector<string>> process(string s){
   return compose(toUpper, toWords)(s);
}

但我们还没有完成。我们已经在新范畴中定义了组合，但是恒等态射是什么？这些不是我们常规的身份函数！它们必须是从 A 型回到 A 型的态射，这意味着它们是以下形式的修饰函数：

But we are not finished yet. We have defined composition in our new category, but what are the identity morphisms? These are not our regular identity functions! They have to be morphisms from type A back to type A, which means they are embellished functions of the form:

Writer<A> identity(A);

Writer<A> identity(A);

它们在组成方面必须表现得像单元。如果你看看我们对组合的定义，你会发现恒等态射应该不加改变地传递它的参数，并且只向日志贡献一个空字符串：

They have to behave like units with respect to composition. If you look at our definition of composition, you’ll see that an identity morphism should pass its argument without change, and only contribute an empty string to the log:

template<class A>
Writer<A> identity(A x) {
    return make_pair(x, "");
}

template<class A>
Writer<A> identity(A x) {
    return make_pair(x, "");
}

您可以轻松地说服自己，我们刚刚定义的范畴确实是合法的范畴。特别是，我们的组合是简单关联的。如果您关注每对的第一个组件所发生的情况，您会发现它只是一个常规函数组合，具有结合性。第二个组件是串联的，并且串联也是关联的。

You can easily convince yourself that the category we have just defined is indeed a legitimate category. In particular, our composition is trivially associative. If you follow what’s happening with the first component of each pair, it’s just a regular function composition, which is associative. The second components are being concatenated, and concatenation is also associative.

精明的读者可能会注意到，很容易将此构造推广到任何幺半群，而不仅仅是字符串幺半群。我们将使用mappendinsidecompose和memptyinside identity（代替+and ""）。确实没有理由限制我们只记录字符串。一个好的库编写者应该能够识别使库工作的最低限度的约束——这里日志库的唯一要求是日志具有幺半群属性。

An astute reader may notice that it would be easy to generalize this construction to any monoid, not just the string monoid. We would use mappend inside compose and mempty inside identity (in place of + and ""). There really is no reason to limit ourselves to logging just strings. A good library writer should be able to identify the bare minimum of constraints that make the library work — here the logging library’s only requirement is that the log have monoidal properties.

5.3 Haskell 编写器

5.3 Writer in Haskell

Haskell 中的相同内容更加简洁，而且我们还从编译器获得了更多帮助。让我们从定义Writer类型开始：

The same thing in Haskell is a little more terse, and we also get a lot more help from the compiler. Let’s start by defining the Writer type:

type Writer a = (a, String)

type Writer a = (a, String)

这里我只是定义一个类型别名，相当于 C++ 中的 a typedef(或using)。该类型Writer由类型变量参数化a，相当于一对aand String。对的语法很简单：只有括号中的两个项目，并用逗号分隔。

Here I’m just defining a type alias, an equivalent of a typedef (or using) in C++. The type Writer is parameterized by a type variable a and is equivalent to a pair of a and String. The syntax for pairs is minimal: just two items in parentheses, separated by a comma.

我们的态射是从任意类型到某种Writer类型的函数：

Our morphisms are functions from an arbitrary type to some Writer type:

a -> Writer b

a -> Writer b

我们将把组合声明为一个有趣的中缀运算符，有时称为“鱼”：

We’ll declare the composition as a funny infix operator, sometimes called the “fish”:

(>=>) :: (a -> Writer b) -> (b -> Writer c) -> (a -> Writer c)

(>=>) :: (a -> Writer b) -> (b -> Writer c) -> (a -> Writer c)

它是一个有两个参数的函数，每个参数都是一个独立的函数，并返回一个函数。第一个参数的类型为(a->Writer b)，第二个参数的类型为(b->Writer c)，结果为(a->Writer c)。

It’s a function of two arguments, each being a function on its own, and returning a function. The first argument is of the type (a->Writer b), the second is (b->Writer c), and the result is (a->Writer c).

这是这个中缀运算符的定义 - 两个参数m1出现m2在可疑符号的两侧：

Here’s the definition of this infix operator — the two arguments m1 and m2 appearing on either side of the fishy symbol:

m1 >=> m2 = \x -> 
  let (y, s1) = m1 x
      (z, s2) = m2 y
  in (z, s1 ++ s2)

m1 >=> m2 = \x -> 
  let (y, s1) = m1 x
      (z, s2) = m2 y
  in (z, s1 ++ s2)

结果是一个只有一个参数的 lambda 函数x。lambda 写成反斜杠——可以将其视为带有截肢的希腊字母 λ。

The result is a lambda function of one argument x. The lambda is written as a backslash — think of it as the Greek letter λ with an amputated leg.

该let表达式允许您声明辅助变量。这里调用的结果m1与一对变量进行模式匹配(y, s1)；m2并且使用第一个模式中的参数调用 的结果y与 相匹配(z, s2)。

The let expression lets you declare auxiliary variables. Here the result of the call to m1 is pattern matched to a pair of variables (y, s1); and the result of the call to m2, with the argument y from the first pattern, is matched to (z, s2).

在 Haskell 中，通常采用模式匹配对，而不是像我们在 C++ 中那样使用访问器。除此之外，两个实现之间有非常简单的对应关系。

It is common in Haskell to pattern match pairs, rather than use accessors, as we did in C++. Other than that there is a pretty straightforward correspondence between the two implementations.

表达式的整体值let在其子句中指定in：这里它是一个对，其第一个组件是z，第二个组件是两个字符串的串联s1++s2。

The overall value of the let expression is specified in its in clause: here it’s a pair whose first component is z and the second component is the concatenation of two strings, s1++s2.

我还将为我们的范畴定义恒等态射，但出于稍后将变得清楚的原因，我将其称为return。

I will also define the identity morphism for our category, but for reasons that will become clear much later, I will call it return.

return :: a -> Writer a
return x = (x, "")

return :: a -> Writer a
return x = (x, "")

为了完整起见，让我们使用 Haskell 版本的修饰函数upCase和toWords：

For completeness, let’s have the Haskell versions of the embellished functions upCase and toWords:

upCase :: String -> Writer String
upCase s = (map toUpper s, "upCase ")

upCase :: String -> Writer String
upCase s = (map toUpper s, "upCase ")

toWords :: String -> Writer [String]
toWords s = (words s, "toWords ")

toWords :: String -> Writer [String]
toWords s = (words s, "toWords ")

该函数map对应于C++ transform. 它将字符函数应用于toUpper字符串s。辅助函数words在标准 Prelude 库中定义。

The function map corresponds to the C++ transform. It applies the character function toUpper to the string s. The auxiliary function words is defined in the standard Prelude library.

最后，两个函数的组合是在fish操作符的帮助下完成的：

Finally, the composition of the two functions is accomplished with the help of the fish operator:

process :: String -> Writer [String]
process = upCase >=> toWords

process :: String -> Writer [String]
process = upCase >=> toWords

5.4克莱斯利范畴

5.4 Kleisli Categories

你可能已经猜到我并没有当场发明这个范畴。这是所谓的 Kleisli 范畴（基于单子的范畴）的一个示例。我们还没有准备好讨论 monad，但我想让您体验一下它们的功能。出于我们有限的目的，Kleisli 范畴具有作为对象的底层编程语言的类型。从类型 A 到类型 B 的态射是使用特定修饰从 A 到派生自 B 的类型的函数。每个 Kleisli 范畴都定义了自己的构成此类态射的方式，以及与该构成相关的恒等态射。（稍后我们将看到不精确的术语“修饰”对应于范畴中的内函子的概念。）

You might have guessed that I haven’t invented this category on the spot. It’s an example of the so called Kleisli category — a category based on a monad. We are not ready to discuss monads yet, but I wanted to give you a taste of what they can do. For our limited purposes, a Kleisli category has, as objects, the types of the underlying programming language. Morphisms from type A to type B are functions that go from A to a type derived from B using the particular embellishment. Each Kleisli category defines its own way of composing such morphisms, as well as the identity morphisms with respect to that composition. (Later we’ll see that the imprecise term “embellishment” corresponds to the notion of an endofunctor in a category.)

我在这篇文章中用作范畴基础的特定 monad 称为writer monad，它用于记录或跟踪函数的执行。它也是在纯计算中嵌入效应的更通用机制的示例。您之前已经看到，我们可以在集合范畴中对编程语言类型和函数进行建模（像往常一样，忽略底部）。在这里，我们将此模型扩展到一个稍微不同的范畴，在该范畴中态射由修饰函数表示，并且它们的组合不仅仅是将一个函数的输出传递到另一个函数的输入。我们还有一个更大的自由度可以玩：构图本身。事实证明，正是这种自由度使得为命令式语言中传统上使用副作用实现的程序提供简单的指称语义成为可能。

The particular monad that I used as the basis of the category in this post is called the writer monad and it’s used for logging or tracing the execution of functions. It’s also an example of a more general mechanism for embedding effects in pure computations. You’ve seen previously that we could model programming-language types and functions in the category of sets (disregarding bottoms, as usual). Here we have extended this model to a slightly different category, a category where morphisms are represented by embellished functions, and their composition does more than just pass the output of one function to the input of another. We have one more degree of freedom to play with: the composition itself. It turns out that this is exactly the degree of freedom which makes it possible to give simple denotational semantics to programs that in imperative languages are traditionally implemented using side effects.

5.5挑战

5.5 Challenge

未定义其参数的所有可能值的函数称为偏函数。它实际上并不是数学意义上的函数，因此它不符合标准的分类模型。但是，它可以由返回修饰类型的函数表示optional：

A function that is not defined for all possible values of its argument is called a partial function. It’s not really a function in the mathematical sense, so it doesn’t fit the standard categorical mold. It can, however, be represented by a function that returns an embellished type optional:

template<class A> class optional {
    bool _isValid;
    A    _value;
public:
    optional()    : _isValid(false) {}
    optional(A v) : _isValid(true), _value(v) {}
    bool isValid() const { return _isValid; }
    A value() const { return _value; }
};

template<class A> class optional {
    bool _isValid;
    A    _value;
public:
    optional()    : _isValid(false) {}
    optional(A v) : _isValid(true), _value(v) {}
    bool isValid() const { return _isValid; }
    A value() const { return _value; }
};

作为示例，以下是修饰函数的实现safe_root：

As an example, here’s the implementation of the embellished function safe_root:

optional<double> safe_root(double x) {
    if (x >= 0) return optional<double>{sqrt(x)};
    else return optional<double>{};
}

optional<double> safe_root(double x) {
    if (x >= 0) return optional<double>{sqrt(x)};
    else return optional<double>{};
}

这是挑战：

Here’s the challenge:

1. 构造偏函数的 Kleisli 范畴（定义复合和恒等）。
2. Construct the Kleisli category for partial functions (define composition and identity).
3. 实现修饰函数safe_reciprocal，返回其参数的有效倒数（如果它不为零）。
4. Implement the embellished function safe_reciprocal that returns a valid reciprocal of its argument, if it’s different from zero.
5. 尽可能编写safe_root并safe_reciprocal实现safe_root_reciprocal计算。sqrt(1/x)
6. Compose safe_root and safe_reciprocal to implement safe_root_reciprocal that calculates sqrt(1/x) whenever possible.

5.6致谢

5.6 Acknowledgments

我感谢 Eric Niebler 阅读了该草案并提供了compose使用 C++14 的高级功能来驱动类型推断的巧妙实现。我能够剪切旧式模板魔法的整个部分，使用类型特征做同样的事情。甩掉包袱！我还感谢 Gershom Bazerman 提供的有用评论帮助我澄清了一些重要观点。

I’m grateful to Eric Niebler for reading the draft and providing the clever implementation of compose that uses advanced features of C++14 to drive type inference. I was able to cut the whole section of old fashioned template magic that did the same thing using type traits. Good riddance! I’m also grateful to Gershom Bazerman for useful comments that helped me clarify some important points.

6.1按照箭头指示

6.1 Follow the Arrows

古希腊剧作家欧里庇得斯曾经说过：“每个人都像是他习惯结交的同伴。” 我们是由我们的关系定义的。没有什么比范畴论更能体现这一点了。如果我们想在一个范畴中挑选出一个特定的对象，我们只能通过描述它与其他对象（及其本身）的关系模式来做到这一点。这些关系由态射定义。

The Ancient Greek playwright Euripides once said: “Every man is like the company he is wont to keep.” We are defined by our relationships. Nowhere is this more true than in category theory. If we want to single out a particular object in a category, we can only do this by describing its pattern of relationships with other objects (and itself). These relationships are defined by morphisms.

范畴论中有一个常见的构造，称为普遍构造，用于根据对象的关系来定义对象。做到这一点的一种方法是选择一种模式，一种由对象和态射构造的特定形状，并在范畴中查找它的所有出现情况。如果它是一个足够常见的模式，并且范畴很大，那么您很可能会获得很多很多的点击率。诀窍是在这些点击中建立某种排名，并选择最适合的。

There is a common construction in category theory called the universal construction for defining objects in terms of their relationships. One way of doing this is to pick a pattern, a particular shape constructed from objects and morphisms, and look for all its occurrences in the category. If it’s a common enough pattern, and the category is large, chances are you’ll have lots and lots of hits. The trick is to establish some kind of ranking among those hits, and pick what could be considered the best fit.

这个过程让人想起我们进行网络搜索的方式。查询就像一个模式。一个非常笼统的查询会给你很大的回忆：很多点击。有些可能相关，有些则不相关。为了消除不相关的命中，您可以优化查询。这提高了它的精度。最后，搜索引擎将对命中进行排名，希望您感兴趣的结果将出现在列表的顶部。

This process is reminiscent of the way we do web searches. A query is like a pattern. A very general query will give you large recall: lots of hits. Some may be relevant, others not. To eliminate irrelevant hits, you refine your query. That increases its precision. Finally, the search engine will rank the hits and, hopefully, the one result that you’re interested in will be at the top of the list.

6.2初始对象

6.2 Initial Object

最简单的形状是单个物体。显然，该形状的实例与给定范畴中的对象一样多。有很多选择。我们需要建立某种排名并尝试找到位于该层次结构顶部的对象。我们唯一可以使用的方法是态射。如果您将态射视为箭头，那么可能存在从范畴的一端到另一端的总体净箭头流。这对于有序范畴（例如部分订单）来说是正确的。我们可以概括对象优先级的概念，如果存在从a到b的箭头（态射），则对象a比对象b “更初始” 。然后，我们将初始对象定义为具有指向所有其他对象的箭头的对象。显然不能保证这样的对象存在，但这没关系。更大的问题是这样的对象可能太多：召回率很好，但精确度不够。解决方案是从有序范畴中获取提示 - 它们最多允许任何两个对象之间有一个箭头：只有一种方法小于或等于另一个对象。这引导我们得到初始对象的定义：

The simplest shape is a single object. Obviously, there are as many instances of this shape as there are objects in a given category. That’s a lot to choose from. We need to establish some kind of ranking and try to find the object that tops this hierarchy. The only means at our disposal are morphisms. If you think of morphisms as arrows, then it’s possible that there is an overall net flow of arrows from one end of the category to another. This is true in ordered categories, for instance in partial orders. We could generalize that notion of object precedence by saying that object a is “more initial” than object b if there is an arrow (a morphism) going from a to b. We would then define the initial object as one that has arrows going to all other objects. Obviously there is no guarantee that such an object exists, and that’s okay. A bigger problem is that there may be too many such objects: The recall is good, but precision is lacking. The solution is to take a hint from ordered categories — they allow at most one arrow between any two objects: there is only one way of being less-than or equal-to another object. Which leads us to this definition of the initial object:

初始对象是对该范畴中的任何对象具有且仅有一个态射的对象。

The initial object is the object that has one and only one morphism going to any object in the category.

然而，即使这样也不能保证初始对象（如果存在）的唯一性。但它保证了次佳的结果：直到同构的唯一性。同构在范畴论中非常重要，所以我很快就会讨论它们。现在，我们只是同意同构的唯一性证明了在初始对象的定义中使用“the”是合理的。

However, even that doesn’t guarantee the uniqueness of the initial object (if one exists). But it guarantees the next best thing: uniqueness up to isomorphism. Isomorphisms are very important in category theory, so I’ll talk about them shortly. For now, let’s just agree that uniqueness up to isomorphism justifies the use of “the” in the definition of the initial object.

以下是一些示例： 部分有序集合（通常称为偏序集）中的初始对象是其最小元素。有些偏序集没有初始对象——比如所有整数的集合，正数和负数，态射具有小于或等于关系。

Here are some examples: The initial object in a partially ordered set (often called a poset) is its least element. Some posets don’t have an initial object — like the set of all integers, positive and negative, with less-than-or-equal relation for morphisms.

在集合和函数范畴中，初始对象是空集。请记住，空集对应于 Haskell 类型Void（C++ 中没有对应的类型），并且Void调用从到任何其他类型的唯一多态函数absurd：

In the category of sets and functions, the initial object is the empty set. Remember, an empty set corresponds to the Haskell type Void (there is no corresponding type in C++) and the unique polymorphic function from Void to any other type is called absurd:

absurd :: Void -> a

absurd :: Void -> a

正是这个态射族构成了Void类型范畴中的初始对象。

It’s this family of morphisms that makes Void the initial object in the category of types.

6.3终端对象

6.3 Terminal Object

让我们继续使用单对象模式，但让我们改变对对象进行排序的方式。如果存在从b到a的态射（注意方向的反转），我们会说对象a比对象 b “更终结” 。我们将寻找一个比该范畴中任何其他对象更终端的对象。再次强调，我们将坚持独特性：

Let’s continue with the single-object pattern, but let’s change the way we rank the objects. We’ll say that object a is “more terminal” than object b if there is a morphism going from b to a (notice the reversal of direction). We’ll be looking for an object that’s more terminal than any other object in the category. Again, we will insist on uniqueness:

终端对象是从该范畴中的任何对象具有且仅有一个态射的对象。

The terminal object is the object with one and only one morphism coming to it from any object in the category.

再说一次，终端对象是唯一的，直至同构，我将很快展示这一点。但首先让我们看一些例子。在偏序集中，终端对象（如果存在）是最大的对象。在集合范畴中，终端对象是单例。我们已经讨论过单例——它们对应于voidC++ 中的类型和 Haskell 中的单元类型()。它是一种只有一个值的类型——在 C++ 中是隐式的，在 Haskell 中是显式的，用 表示()。我们还确定从任何类型到单位类型都有一个且仅有一个纯函数：

And again, the terminal object is unique, up to isomorphism, which I will show shortly. But first let’s look at some examples. In a poset, the terminal object, if it exists, is the biggest object. In the category of sets, the terminal object is a singleton. We’ve already talked about singletons — they correspond to the void type in C++ and the unit type () in Haskell. It’s a type that has only one value — implicit in C++ and explicit in Haskell, denoted by (). We’ve also established that there is one and only one pure function from any type to the unit type:

unit :: a -> ()
unit _ = ()

unit :: a -> ()
unit _ = ()

因此终端对象的所有条件都得到满足。

so all the conditions for the terminal object are satisfied.

请注意，在此示例中，唯一性条件至关重要，因为还有其他集合（实际上，所有集合，除了空集合）都具有来自每个集合的传入态射。例如，为每种类型定义了一个布尔值函数（谓词）：

Notice that in this example the uniqueness condition is crucial, because there are other sets (actually, all of them, except for the empty set) that have incoming morphisms from every set. For instance, there is a Boolean-valued function (a predicate) defined for every type:

yes :: a -> Bool
yes _ = True

yes :: a -> Bool
yes _ = True

但Bool不是终端对象。Bool每种类型至少有一个多值函数：

But Bool is not a terminal object. There is at least one more Bool-valued function from every type:

no :: a -> Bool
no _ = False

no :: a -> Bool
no _ = False

坚持唯一性为我们提供了正确的精度，将终端对象的定义缩小为一种类型。

Insisting on uniqueness gives us just the right precision to narrow down the definition of the terminal object to just one type.

6.4对偶性

6.4 Duality

您会情不自禁地注意到我们定义初始对象和最终对象的方式之间的对称性。两者之间唯一的区别是态射的方向。事实证明，对于任何范畴 C，我们只需颠倒所有箭头即可定义相反的范畴C ^{op 。}只要我们同时重新定义组合，相反的范畴就会自动满足一个范畴的所有要求。如果原始态射f::a->b和g::b->c组成为h::a->cwith h=g∘f，则逆态射fop::b->a和gop::c->b组成为hop::c->awith hop=fop∘gop。反转身份箭头是（双关语警报！）无操作。

You can’t help but to notice the symmetry between the way we defined the initial object and the terminal object. The only difference between the two was the direction of morphisms. It turns out that for any category C we can define the opposite category C^op just by reversing all the arrows. The opposite category automatically satisfies all the requirements of a category, as long as we simultaneously redefine composition. If original morphisms f::a->b and g::b->c composed to h::a->c with h=g∘f, then the reversed morphisms fop::b->a and gop::c->b will compose to hop::c->a with hop=fop∘gop. And reversing the identity arrows is a (pun alert!) no-op.

对偶性是范畴的一个非常重要的属性，因为它使每个研究范畴论的数学家的生产力加倍。对于你提出的每一个结构，都有它的反面；对于你证明的每一个定理，你都可以免费获得一个。相反范畴中的结构通常以“co”为前缀，因此有乘积和余积、单子和共单子、锥体和可锥体、极限和余极限等等。但没有 cocomonad，因为反转箭头两次可以让我们回到原始状态。

Duality is a very important property of categories because it doubles the productivity of every mathematician working in category theory. For every construction you come up with, there is its opposite; and for every theorem you prove, you get one for free. The constructions in the opposite category are often prefixed with “co”, so you have products and coproducts, monads and comonads, cones and cocones, limits and colimits, and so on. There are no cocomonads though, because reversing the arrows twice gets us back to the original state.

由此可见，终端对象是相反范畴中的初始对象。

It follows then that a terminal object is the initial object in the opposite category.

6.5同构

6.5 Isomorphisms

作为程序员，我们很清楚定义相等性是一项艰巨的任务。两个对象相等意味着什么？它们是否必须占用内存中的相同位置（指针相等）？或者它们所有组成部分的值相等就足够了吗？如果一个复数表示为实部和虚部，另一个表示为模数和角度，两个复数是否相等？你可能认为数学家会弄清楚平等的含义，但他们没有。他们有同样的问题，即平等的多个相互竞争的定义。同伦型论有命题平等、内涵平等、外延平等、路径平等。还有较弱的同构概念，甚至较弱的等价概念。

As programmers, we are well aware that defining equality is a nontrivial task. What does it mean for two objects to be equal? Do they have to occupy the same location in memory (pointer equality)? Or is it enough that the values of all their components are equal? Are two complex numbers equal if one is expressed as the real and imaginary part, and the other as modulus and angle? You’d think that mathematicians would have figured out the meaning of equality, but they haven’t. They have the same problem of multiple competing definitions for equality. There is the propositional equality, intensional equality, extensional equality, and equality as a path in homotopy type theory. And then there are the weaker notions of isomorphism, and even weaker of equivalence.

直觉是同构对象看起来是一样的——它们具有相同的形状。这意味着一个对象的每个部分都以一对一的映射方式对应于另一个对象的某些部分。据我们的仪器判断，这两个物体是彼此的完美复制品。从数学上讲，这意味着存在从对象a到对象b 的映射，并且存在从对象b回到对象a的映射，并且它们是彼此的逆。在范畴论中，我们用态射代替映射。同构是可逆的态射；或一对态射，其中一个是另一个的逆。

The intuition is that isomorphic objects look the same — they have the same shape. It means that every part of one object corresponds to some part of another object in a one-to-one mapping. As far as our instruments can tell, the two objects are a perfect copy of each other. Mathematically it means that there is a mapping from object a to object b, and there is a mapping from object b back to object a, and they are the inverse of each other. In category theory we replace mappings with morphisms. An isomorphism is an invertible morphism; or a pair of morphisms, one being the inverse of the other.

我们从复合和恒等的角度来理解逆：态射g是态射f的逆，如果它们的复合是恒等态射。这实际上是两个方程，因为有两种方法可以构成两个态射：

We understand the inverse in terms of composition and identity: Morphism g is the inverse of morphism f if their composition is the identity morphism. These are actually two equations because there are two ways of composing two morphisms:

f . g = id
g . f = id

f . g = id
g . f = id

当我说初始（终端）对象在同构上是唯一的时，我的意思是任何两个初始（终端）对象都是同构的。这其实很容易看出。假设我们有两个初始对象 i ₁和 i ₂。由于 i ₁是初始的，因此从 i ₁到 i ₂存在唯一的态射f。同样，由于 i ₂是初始的，因此从 i ₂到 i ₁存在唯一的态射g。这两个态射的组成是什么？

When I said that the initial (terminal) object was unique up to isomorphism, I meant that any two initial (terminal) objects are isomorphic. That’s actually easy to see. Let’s suppose that we have two initial objects i₁ and i₂. Since i₁ is initial, there is a unique morphism f from i₁ to i₂. By the same token, since i₂ is initial, there is a unique morphism g from i₂ to i₁. What’s the composition of these two morphisms?

该图中的所有态射都是唯一的

All morphisms in this diagram are unique

组合g∘f必须是从 i ₁到 i ₁的态射。但 i _{1是初始的，因此从 i 1}到 i ₁只能有一个态射。_{因为我们在一个范畴中，所以我们知道从 i 1}到 i ₁存在恒等态射，并且由于只有一个空间，所以一定是它。因此g∘f等于恒等式。类似地，f∘g必须等于恒等，因为从 i ₂回到 i ₂只能有一个态射。这证明f和g必定互为倒数。因此任何两个初始对象都是同构的。

The composition g∘f must be a morphism from i₁ to i₁. But i₁ is initial so there can only be one morphism going from i₁ to i₁. Since we are in a category, we know that there is an identity morphism from i₁ to i₁, and since there is room for only one, that must be it. Therefore g∘f is equal to identity. Similarly, f∘g must be equal to identity, because there can be only one morphism from i₂ back to i₂. This proves that f and g must be the inverse of each other. Therefore any two initial objects are isomorphic.

请注意，在这个证明中，我们使用了从初始对象到自身的态射的唯一性。如果没有它，我们就无法证明“同构”部分。但为什么我们需要f和g的唯一性？因为初始对象不仅在同构上是唯一的，而且在唯一同构上也是唯一的。原则上，两个对象之间可能存在多个同构，但这里的情况并非如此。这种“唯一性到唯一同构”是所有普遍构造的重要属性。

Notice that in this proof we used the uniqueness of the morphism from the initial object to itself. Without that we couldn’t prove the “up to isomorphism” part. But why do we need the uniqueness of f and g? Because not only is the initial object unique up to isomorphism, it is unique up to unique isomorphism. In principle, there could be more than one isomorphism between two objects, but that’s not the case here. This “uniqueness up to unique isomorphism” is the important property of all universal constructions.

6.6产品

6.6 Products

下一个通用结构是产品的结构。我们知道两个集合的笛卡尔积是什么：它是一组对。但是，连接产品集与其组成集的模式是什么？如果我们能弄清楚这一点，我们就能将其推广到其他范畴。

The next universal construction is that of a product. We know what a cartesian product of two sets is: it’s a set of pairs. But what’s the pattern that connects the product set with its constituent sets? If we can figure that out, we’ll be able to generalize it to other categories.

我们只能说，有两个函数，即从产品到每个成分的投影。在 Haskell 中，这两个函数被称为fstand snd，它们分别选择一对的第一个和第二个组件：

All we can say is that there are two functions, the projections, from the product to each of the constituents. In Haskell, these two functions are called fst and snd and they pick, respectively, the first and the second component of a pair:

fst :: (a, b) -> a
fst (x, y) = x

fst :: (a, b) -> a
fst (x, y) = x

snd :: (a, b) -> b
snd (x, y) = y

snd :: (a, b) -> b
snd (x, y) = y

在这里，函数是通过模式匹配其参数来定义的：匹配任何对的模式是(x, y)，并将其组件提取到变量x和中y。

Here, the functions are defined by pattern matching their arguments: the pattern that matches any pair is (x, y), and it extracts its components into variables x and y.

使用通配符可以进一步简化这些定义：

These definitions can be simplified even further with the use of wildcards:

fst (x, _) = x
snd (_, y) = y

fst (x, _) = x
snd (_, y) = y

在C++中，我们会使用模板函数，例如：

In C++, we would use template functions, for instance:

template<class A, class B>
A fst(pair<A, B> const & p) {
    return p.first;
}

template<class A, class B>
A fst(pair<A, B> const & p) {
    return p.first;
}

有了这些看似非常有限的知识，让我们尝试在集合范畴中定义对象和态射的模式，这将引导我们构建两个集合 a 和b的乘积。该模式由一个对象c和两个态射p和q组成，分别将其连接到a和b ：

Equipped with this seemingly very limited knowledge, let’s try to define a pattern of objects and morphisms in the category of sets that will lead us to the construction of a product of two sets, a and b. This pattern consists of an object c and two morphisms p and q connecting it to a and b, respectively:

p :: c -> a
q :: c -> b

p :: c -> a
q :: c -> b

所有符合此模式的c都将被视为该产品的候选者。可能有很多。

All cs that fit this pattern will be considered candidates for the product. There may be lots of them.

例如，让我们选择两种 Haskell 类型Int和作为我们的成分Bool，并获取其产品的候选样本。

For instance, let’s pick, as our constituents, two Haskell types, Int and Bool, and get a sampling of candidates for their product.

这是一个：Int。可以被视为和Int的乘积的候选者吗？是的，它可以——以下是它的预测：IntBool

Here’s one: Int. Can Int be considered a candidate for the product of Int and Bool? Yes, it can — and here are its projections:

p :: Int -> Int
p x = x

q :: Int -> Bool
q _ = True

p :: Int -> Int
p x = x

q :: Int -> Bool
q _ = True

这是相当蹩脚的，但它符合标准。

That’s pretty lame, but it matches the criteria.

这是另一个：(Int, Int, Bool)。它是三个元素的元组，或三元组。以下两个态射使其成为合法的候选者（我们在三元组上使用模式匹配）：

Here’s another one: (Int, Int, Bool). It’s a tuple of three elements, or a triple. Here are two morphisms that make it a legitimate candidate (we are using pattern matching on triples):

p :: (Int, Int, Bool) -> Int
p (x, _, _) = x

q :: (Int, Int, Bool) -> Bool
q (_, _, b) = b

p :: (Int, Int, Bool) -> Int
p (x, _, _) = x

q :: (Int, Int, Bool) -> Bool
q (_, _, b) = b

您可能已经注意到，虽然我们的第一个候选太小了，但它只覆盖了Int产品的尺寸；第二个太大了——它虚假地复制了Int维度。

You may have noticed that while our first candidate was too small — it only covered the Int dimension of the product; the second was too big — it spuriously duplicated the Int dimension.

但我们还没有探索通用结构的另一部分：排名。我们希望能够比较模式的两个实例。我们想要将一个候选对象c及其两个投影p和q与另一个候选对象c'及其两个投影p'和q'进行比较。我们想说，如果从c'到c存在态射m ，则c比c' “更好” ——但这太弱了。我们还希望它的预测比c'的预测“更好”或“更普遍” 。这意味着投影p'和q'可以使用m从p和q重建：

But we haven’t explored yet the other part of the universal construction: the ranking. We want to be able to compare two instances of our pattern. We want to compare one candidate object c and its two projections p and q with another candidate object c’ and its two projections p’ and q’. We would like to say that c is “better” than c’ if there is a morphism m from c’ to c — but that’s too weak. We also want its projections to be “better,” or “more universal,” than the projections of c’. What it means is that the projections p’ and q’ can be reconstructed from p and q using m:

p’ = p . m
q’ = q . m

p’ = p . m
q’ = q . m

查看这些方程的另一种方式是m将 p'和q'因式分解 。假设这些方程是自然数，并且点是乘法：m是p'和q'共享的公因子。

Another way of looking at these equation is that m factorizes p’ and q’. Just pretend that these equations are in natural numbers, and the dot is multiplication: m is a common factor shared by p’ and q’.

(Int, Bool)为了建立一些直觉，让我向您展示具有两个规范投影的对，fst并且snd确实比我之前提出的两个候选更好。

Just to build some intuitions, let me show you that the pair (Int, Bool) with the two canonical projections, fst and snd is indeed better than the two candidates I presented before.

m第一个候选者的映射是：

The mapping m for the first candidate is:

m :: Int -> (Int, Bool)
m x = (x, True)

m :: Int -> (Int, Bool)
m x = (x, True)

事实上，这两个投影p和q可以重构为：

Indeed, the two projections, p and q can be reconstructed as:

p x = fst (m x) = x
q x = snd (m x) = True

p x = fst (m x) = x
q x = snd (m x) = True

第二个例子的m也同样是唯一确定的：

The m for the second example is similarly uniquely determined:

m (x, _, b) = (x, b)

m (x, _, b) = (x, b)

我们能够证明这(Int, Bool)比两位候选人中的任何一位都更好。让我们看看为什么相反的情况不成立。我们能找到一些m'可以帮助我们从fst和重建 和的东西吗？sndpq

We were able to show that (Int, Bool) is better than either of the two candidates. Let’s see why the opposite is not true. Could we find some m' that would help us reconstruct fst and snd from p and q?

fst = p . m’
snd = q . m’

fst = p . m’
snd = q . m’

在我们的第一个示例中，q总是返回True，并且我们知道有一些对的第二个分量是False。我们无法snd从重建q。

In our first example, q always returned True and we know that there are pairs whose second component is False. We can’t reconstruct snd from q.

第二个示例有所不同：在运行 或 后我们保留了足够的信息p，但是分解和 的q方法不止一种。因为 和都忽略了三元组的第二个组成部分，所以我们可以在其中放入任何内容。我们可以有：fstsndpqm’

The second example is different: we retain enough information after running either p or q, but there is more than one way to factorize fst and snd. Because both p and q ignore the second component of the triple, our m’ can put anything in it. We can have:

m’ (x, b) = (x, x, b)

m’ (x, b) = (x, x, b)

或者

or

m’ (x, b) = (x, 42, b)

m’ (x, b) = (x, 42, b)

等等。

and so on.

将它们放在一起，给定任何c具有两个投影p和 的类型，笛卡尔积q都有一个独特的mfrom来分解它们。事实上，它只是将和组合成一对。c(a, b)pq

Putting it all together, given any type c with two projections p and q, there is a unique m from c to the cartesian product (a, b) that factorizes them. In fact, it just combines p and q into a pair.

m :: c -> (a, b)
m x = (p x, q x)

m :: c -> (a, b)
m x = (p x, q x)

这使得笛卡尔积成为(a, b)我们的最佳匹配，这意味着这种通用构造适用于集合的范畴。它选择任意两个集合的乘积。

That makes the cartesian product (a, b) our best match, which means that this universal construction works in the category of sets. It picks the product of any two sets.

现在让我们忘记集合并使用相同的通用构造来定义任何范畴中的两个对象的乘积。这样的产品并不总是存在，但当它存在时，它是独一无二的，甚至具有独特的同构性。

Now let’s forget about sets and define a product of two objects in any category using the same universal construction. Such product doesn’t always exist, but when it does, it is unique up to a unique isomorphism.

两个对象a和b的乘积是配备有两个投影的对象c，这样对于配备有两个投影的任何其他对象c '，存在从c'到c的唯一态射m来因式分解这些投影。

A product of two objects a and b is the object c equipped with two projections such that for any other object c’ equipped with two projections there is a unique morphism m from c’ to c that factorizes those projections.

从两个候选产生因式分解函数的（高阶）函数m有时称为因式分解器。在我们的例子中，它将是函数：

A (higher order) function that produces the factorizing function m from two candidates is sometimes called the factorizer. In our case, it would be the function:

factorizer :: (c -> a) -> (c -> b) -> (c -> (a, b))
factorizer p q = \x -> (p x, q x)

factorizer :: (c -> a) -> (c -> b) -> (c -> (a, b))
factorizer p q = \x -> (p x, q x)

6.7余积

6.7 Coproduct

就像范畴论中的每个构造一样，该乘积也有一个对偶，称为余积。当我们反转乘积模式中的箭头时，我们最终得到一个对象c ，该对象 c配备了两个注入,i和j：从a和b到c的态射。

Like every construction in category theory, the product has a dual, which is called the coproduct. When we reverse the arrows in the product pattern, we end up with an object c equipped with two injections, i and j: morphisms from a and b to c.

i :: a -> c
j :: b -> c

i :: a -> c
j :: b -> c

排名也是颠倒的：如果存在从c到c ' 的态射m将注入因式分解，则对象c比配备注入i'和j'的对象 c' “更好” ：

The ranking is also inverted: object c is “better” than object c’ that is equipped with the injections i’ and j’ if there is a morphism m from c to c’ that factorizes the injections:

i' = m . i
j' = m . j

i' = m . i
j' = m . j

“最好的”这样的对象，具有将其连接到任何其他模式的唯一态射，称为余积，并且如果存在，则在唯一同构上是唯一的。

The “best” such object, one with a unique morphism connecting it to any other pattern, is called a coproduct and, if it exists, is unique up to unique isomorphism.

两个对象a和b的余积是配备有两个注入的对象c，这样对于配备有两个注入的任何其他对象c'，存在从c到c' 的唯一态射m来因式分解这些注入。

A coproduct of two objects a and b is the object c equipped with two injections such that for any other object c’ equipped with two injections there is a unique morphism m from c to c’ that factorizes those injections.

在集合范畴中，余积是两个集合的不相交并。a和b的不相交并集的元素是a的元素或b的元素。如果两个集合重叠，则不相交的并集包含公共部分的两个副本。您可以将不相交联合的元素视为用指定其来源的标识符进行标记。

In the category of sets, the coproduct is the disjoint union of two sets. An element of the disjoint union of a and b is either an element of a or an element of b. If the two sets overlap, the disjoint union contains two copies of the common part. You can think of an element of a disjoint union as being tagged with an identifier that specifies its origin.

对于程序员来说，从类型角度理解余积更容易：它是两种类型的标记并集。C++ 支持联合，但它们没有标记。这意味着在您的程序中，您必须以某种方式跟踪联盟的哪个成员是有效的。要创建标记联合，您必须定义一个标记（枚举）并将其与联合结合起来。例如，anint和 a的标记联合char const *可以实现为：

For a programmer, it’s easier to understand a coproduct in terms of types: it’s a tagged union of two types. C++ supports unions, but they are not tagged. It means that in your program you have to somehow keep track which member of the union is valid. To create a tagged union, you have to define a tag — an enumeration — and combine it with the union. For instance, a tagged union of an int and a char const * could be implemented as:

struct Contact {
    enum { isPhone, isEmail } tag;
    union { int phoneNum; char const * emailAddr; };
};

struct Contact {
    enum { isPhone, isEmail } tag;
    union { int phoneNum; char const * emailAddr; };
};

这两个注入可以作为构造函数或函数来实现。例如，这是作为函数的第一次注入PhoneNum：

The two injections can either be implemented as constructors or as functions. For instance, here’s the first injection as a function PhoneNum:

Contact PhoneNum(int n) {
    Contact c;
    c.tag = isPhone;
    c.phoneNum = n;
    return c;
}

Contact PhoneNum(int n) {
    Contact c;
    c.tag = isPhone;
    c.phoneNum = n;
    return c;
}

它将一个整数注入到Contact.

It injects an integer into Contact.

标记联合也称为变体，并且在 boost 库中有一个非常通用的变体实现boost::variant。

A tagged union is also called a variant, and there is a very general implementation of a variant in the boost library, boost::variant.

在 Haskell 中，您可以通过用竖线分隔数据构造函数来将任何数据类型组合到标记联合中。该Contact示例翻译为声明：

In Haskell, you can combine any data types into a tagged union by separating data constructors with a vertical bar. The Contact example translates into the declaration:

data Contact = PhoneNum Int | EmailAddr String

data Contact = PhoneNum Int | EmailAddr String

在这里，PhoneNum和EmailAddr既充当构造函数（注入），又充当模式匹配的标签（稍后会详细介绍）。例如，这是使用电话号码构建联系人的方式：

Here, PhoneNum and EmailAddr serve both as constructors (injections), and as tags for pattern matching (more about this later). For instance, this is how you would construct a contact using a phone number:

helpdesk :: Contact;
helpdesk = PhoneNum 2222222

helpdesk :: Contact;
helpdesk = PhoneNum 2222222

与 Haskell 中作为原语对内置的乘积的规范实现不同，余积的规范实现是一种名为 的数据类型Either，它在标准 Prelude 中定义为：

Unlike the canonical implementation of the product that is built into Haskell as the primitive pair, the canonical implementation of the coproduct is a data type called Either, which is defined in the standard Prelude as:

Either a b = Left a | Right b

Either a b = Left a | Right b

它由两种类型参数化，a并且b有两个构造函数：Left一个采用类型 的值a，另一个Right采用类型 的值b。

It is parameterized by two types, a and b and has two constructors: Left that takes a value of type a, and Right that takes a value of type b.

正如我们为乘积定义了因式分解器一样，我们也可以为余积定义因式分解器。给定一个候选类型c和两个候选注入i和j，因子分解器Either产生因子分解函数：

Just as we’ve defined the factorizer for a product, we can define one for the coproduct. Given a candidate type c and two candidate injections i and j, the factorizer for Either produces the factoring function:

factorizer :: (a -> c) -> (b -> c) -> Either a b -> c
factorizer i j (Left a)  = i a
factorizer i j (Right b) = j b

factorizer :: (a -> c) -> (b -> c) -> Either a b -> c
factorizer i j (Left a)  = i a
factorizer i j (Right b) = j b

6.8不对称性

6.8 Asymmetry

我们已经看到了两组双重定义： 终端对象的定义可以从初始对象的定义中通过反转箭头方向得到；类似地，可以从乘积的定义得到联积的定义。然而，在集合范畴中，初始对象与最终对象有很大不同，余积与乘积也有很大不同。稍后我们将看到乘积的行为类似于乘法，终端对象扮演一的角色；而余积的行为更像是求和，初始对象扮演零的角色。特别是，对于有限集，乘积的大小是各个集合大小的乘积，而余积的大小是大小的总和。

We’ve seen two set of dual definitions: The definition of a terminal object can be obtained from the definition of the initial object by reversing the direction of arrows; in a similar way, the definition of the coproduct can be obtained from that of the product. Yet in the category of sets the initial object is very different from the final object, and coproduct is very different from product. We’ll see later that product behaves like multiplication, with the terminal object playing the role of one; whereas coproduct behaves more like the sum, with the initial object playing the role of zero. In particular, for finite sets, the size of the product is the product of the sizes of individual sets, and the size of the coproduct is the sum of the sizes.

这表明集合的范畴关于箭头的反转不是对称的。

This shows that the category of sets is not symmetric with respect to the inversion of arrows.

请注意，虽然空集对任何集合（函数absurd）都有唯一的态射，但它没有返回态射。单例集合具有来自任何集合的唯一态射，但它也具有每个集合的传出态射（空集合除外）。正如我们之前所看到的，这些来自终端对象的传出态射在选取其他集合的元素方面发挥着非常重要的作用（空集合没有元素，因此没有什么可选取的）。

Notice that while the empty set has a unique morphism to any set (the absurd function), it has no morphisms coming back. The singleton set has a unique morphism coming to it from any set, but it also has outgoing morphisms to every set (except for the empty one). As we’ve seen before, these outgoing morphisms from the terminal object play a very important role of picking elements of other sets (the empty set has no elements, so there’s nothing to pick).

正是单例集与乘积的关系将其与联积区分开来。考虑使用由单位类型表示的单例集()，作为产品模式的另一个（非常差的）候选者。为其配备两个投影p和q: 从单例到每个组成集的函数。每个元素都从任一集合中选择一个具体元素。m因为乘积是通用的，所以从我们的候选者（单例）到乘积也存在（独特的）态射。这种态射从乘积集中选择一个元素——它选择一个具体的对。它还分解了两个投影：

It’s the relationship of the singleton set to the product that sets it apart from the coproduct. Consider using the singleton set, represented by the unit type (), as yet another — vastly inferior — candidate for the product pattern. Equip it with two projections p and q: functions from the singleton to each of the constituent sets. Each selects a concrete element from either set. Because the product is universal, there is also a (unique) morphism m from our candidate, the singleton, to the product. This morphism selects an element from the product set — it selects a concrete pair. It also factorizes the two projections:

p = fst . m
q = snd . m

p = fst . m
q = snd . m

当作用于单例值()（单例集的唯一元素）时，这两个方程变为：

When acting on the singleton value (), the only element of the singleton set, these two equations become:

p () = fst (m ())
q () = snd (m ())

p () = fst (m ())
q () = snd (m ())

由于m ()是 由 选取的乘积的元素，这些方程告诉用户，从第一组 中m选取的元素是由 选取的对中的第一个分量。类似地，等于第二个分量。这与我们的理解完全一致，即产品的元素是来自组成集合的元素对。pp ()mq ()

Since m () is the element of the product picked by m, these equations tell use that the element picked by p from the first set, p (), is the first component of the pair picked by m. Similarly, q () is equal to the second component. This is in total agreement with our understanding that elements of the product are pairs of elements from the constituent sets.

对余积没有这样简单的解释。我们可以尝试将单例集作为余积的候选者，试图从中提取元素，但是我们将有两次注入进入其中，而不是从中产生两个投影。他们不会告诉我们任何有关其来源的信息（事实上，我们已经看到他们忽略了输入参数）。从余积到我们的单例的独特态射也不会。从初始对象的方向看与从末端看时，集合的范畴看起来非常不同。

There is no such simple interpretation of the coproduct. We could try the singleton set as a candidate for a coproduct, in an attempt to extract the elements from it, but there we would have two injections going into it rather than two projections coming out of it. They’d tell us nothing about their sources (in fact, we’ve seen that they ignore the input parameter). Neither would the unique morphism from the coproduct to our singleton. The category of sets just looks very different when seen from the direction of the initial object than it does when seen from the terminal end.

这不是集合的内在属性，而是函数的属性，我们在Set中将其用作态射。一般来说，函数是不对称的。让我解释。

This is not an intrinsic property of sets, it’s a property of functions, which we use as morphisms in Set. Functions are, in general, asymmetric. Let me explain.

必须为其域集的每个元素定义一个函数（在编程中，我们称其为总函数），但它不必覆盖整个共域。我们已经看到了一些极端的情况：来自单例集合的函数——仅选择共域中的单个元素的函数。（实际上，来自空集的函数才是真正的极值。）当定义域的大小远小于余域的大小时，我们通常将此类函数视为将域嵌入到余域中。例如，我们可以将单例集中的函数视为将其单个元素嵌入到共域中。我将它们称为嵌入函数，但数学家更喜欢给相反的名称起一个名字：紧密填充其共域的函数称为满射或到。

A function must be defined for every element of its domain set (in programming, we call it a total function), but it doesn’t have to cover the whole codomain. We’ve seen some extreme cases of it: functions from a singleton set — functions that select just a single element in the codomain. (Actually, functions from an empty set are the real extremes.) When the size of the domain is much smaller than the size of the codomain, we often think of such functions as embedding the domain in the codomain. For instance, we can think of a function from a singleton set as embedding its single element in the codomain. I call them embedding functions, but mathematicians prefer to give a name to the opposite: functions that tightly fill their codomains are called surjective or onto.

不对称的另一个来源是函数可以将域集的许多元素映射到共域的一个元素。他们可以让它们崩溃。极端情况是将整个集合映射到单个实例的函数。您已经看到了unit执行此操作的多态函数。崩溃只能通过组合来加剧。两个折叠函数的组合比单个函数的折叠程度更高。数学家对非折叠函数有一个名字：他们称它们为单射函数或一对一函数

The other source of asymmetry is that functions are allowed to map many elements of the domain set into one element of the codomain. They can collapse them. The extreme case are functions that map whole sets into a singleton. You’ve seen the polymorphic unit function that does just that. The collapsing can only be compounded by composition. A composition of two collapsing functions is even more collapsing than the individual functions. Mathematicians have a name for non-collapsing functions: they call them injective or one-to-one

当然，有些函数既不嵌入也不折叠。它们被称为双射，并且它们是真正对称的，因为它们是可逆的。在集合范畴中，同构与双射相同。

Of course there are some functions that are neither embedding nor collapsing. They are called bijections and they are truly symmetric, because they are invertible. In the category of sets, an isomorphism is the same as a bijection.

6.9挑战

6.9 Challenges

1. 表明终端对象在唯一同构上是唯一的。
2. Show that the terminal object is unique up to unique isomorphism.
3. 偏序集中两个对象的乘积是什么？提示：使用通用结构。
4. What is a product of two objects in a poset? Hint: Use the universal construction.
5. 偏序集中两个对象的余积是什么？
6. What is a coproduct of two objects in a poset?
7. Either用您最喜欢的语言（Haskell 除外）将 Haskell 的等效项实现为泛型类型。
8. Implement the equivalent of Haskell Either as a generic type in your favorite language (other than Haskell).

9. 证明这是一个比配备两次注射Either“更好”的副产品：int

   int i(int n) { return n; }
   int j(bool b) { return b? 0: 1; }

   提示：定义一个函数

   int m(Either const & e);

   因式分解i和j。

10. Show that Either is a “better” coproduct than int equipped with two injections:

    int i(int n) { return n; }
    int j(bool b) { return b? 0: 1; }

    Hint: Define a function

    int m(Either const & e);

    that factorizes i and j.

11. 继续上一个问题：你如何论证int两次注射i和j不能“更好”于Either？
12. Continuing the previous problem: How would you argue that int with the two injections i and j cannot be “better” than Either?

13. 仍在继续：这些注射怎么样？

    int i(int n) { 
        if (n < 0) return n; 
        return n + 2;
    }
    int j(bool b) { return b? 0: 1; }

14. Still continuing: What about these injections?

    int i(int n) { 
        if (n < 0) return n; 
        return n + 2;
    }
    int j(bool b) { return b? 0: 1; }

15. 为 的余积提出一个较差的候选者int，bool它不能比 更好，Either因为它允许从 到 的多个可接受的态射Either。
16. Come up with an inferior candidate for a coproduct of int and bool that cannot be better than Either because it allows multiple acceptable morphisms from it to Either.

6.10参考书目

6.10 Bibliography

1. Catsters、产品和联产品视频。
2. The Catsters, Products and Coproducts video.

6.11致谢

6.11 Acknowledments

我感谢 Gershom Bazerman 在发表之前审阅了这篇文章并激发了讨论。

I’m grateful to Gershom Bazerman for reviewing this post before publication and for stimulating discussions.

7.1产品类型

7.1 Product Types

编程语言中两种类型的乘积的规范实现是一对。在 Haskell 中，pair 是原始类型构造函数；在 C++ 中，它是标准库中定义的相对复杂的模板。

The canonical implementation of a product of two types in a programming language is a pair. In Haskell, a pair is a primitive type constructor; in C++ it’s a relatively complex template defined in the Standard Library.

Pair 不严格可交换：pair(Int, Bool)不能替代pair (Bool, Int)，即使它们携带相同的信息。然而，它们在同构上是可交换的——同构由函数给出swap（这是它自己的逆）：

Pairs are not strictly commutative: a pair (Int, Bool) cannot be substituted for a pair (Bool, Int), even though they carry the same information. They are, however, commutative up to isomorphism — the isomorphism being given by the swap function (which is its own inverse):

swap :: (a, b) -> (b, a)
swap (x, y) = (y, x)

swap :: (a, b) -> (b, a)
swap (x, y) = (y, x)

您可以将这两对视为简单地使用不同的格式来存储相同的数据。这就像大端与小端一样。

You can think of the two pairs as simply using a different format for storing the same data. It’s just like big endian vs. little endian.

您可以通过在对内嵌套对来将任意数量的类型组合到产品中，但有一种更简单的方法：嵌套对相当于元组。这是不同方式的嵌套对是同构的结果。如果您想将三种类型按顺序组合在一个产品中， a、b、 和，您可以通过两种方式进行：c

You can combine an arbitrary number of types into a product by nesting pairs inside pairs, but there is an easier way: nested pairs are equivalent to tuples. It’s the consequence of the fact that different ways of nesting pairs are isomorphic. If you want to combine three types in a product, a, b, and c, in this order, you can do it in two ways:

((a, b), c)

((a, b), c)

或者

or

(a, (b, c))

(a, (b, c))

这些类型是不同的 - 您不能将其中一个传递给需要另一个的函数 - 但它们的元素是一一对应的。有一个函数可以将一个映射到另一个：

These types are different — you can’t pass one to a function that expects the other — but their elements are in one-to-one correspondence. There is a function that maps one to another:

alpha :: ((a, b), c) -> (a, (b, c))
alpha ((x, y), z) = (x, (y, z))

alpha :: ((a, b), c) -> (a, (b, c))
alpha ((x, y), z) = (x, (y, z))

并且这个函数是可逆的：

and this function is invertible:

alpha_inv :: (a, (b, c)) -> ((a, b), c)
alpha_inv  (x, (y, z)) = ((x, y), z)

alpha_inv :: (a, (b, c)) -> ((a, b), c)
alpha_inv  (x, (y, z)) = ((x, y), z)

所以这是一个同构。这些只是重新打包相同数据的不同方式。

so it’s an isomorphism. These are just different ways of repackaging the same data.

您可以将产品类型的创建解释为类型上的二元运算。从这个角度来看，上面的同构看起来非常像我们在幺半群中看到的结合律：

You can interpret the creation of a product type as a binary operation on types. From that perspective, the above isomorphism looks very much like the associativity law we’ve seen in monoids:

(a * b) * c = a * (b * c)

(a * b) * c = a * (b * c)

不同的是，在幺半群的情况下，两种组合乘积的方式是相等的，而在这里它们只是“同构”相等。

Except that, in the monoid case, the two ways of composing products were equal, whereas here they are only equal “up to isomorphism.”

如果我们可以接受同构，并且不坚持严格相等，我们可以更进一步，证明单位类型()是乘积的单位，就像 1 是乘法单位一样。事实上，某种类型的值与单位的配对a不会添加任何信息。方式：

If we can live with isomorphisms, and don’t insist on strict equality, we can go even further and show that the unit type, (), is the unit of the product the same way 1 is the unit of multiplication. Indeed, the pairing of a value of some type a with a unit doesn’t add any information. The type:

(a, ())

(a, ())

同构于a. 这是同构：

is isomorphic to a. Here’s the isomorphism:

rho :: (a, ()) -> a
rho (x, ()) = x

rho :: (a, ()) -> a
rho (x, ()) = x

rho_inv :: a -> (a, ())
rho_inv x = (x, ())

rho_inv :: a -> (a, ())
rho_inv x = (x, ())

这些观察可以通过说Set（集合的范畴）是一个幺半群范畴来形式化。它是一个范畴，也是一个幺半群，从某种意义上说，您可以将对象相乘（在这里，采用它们的笛卡尔积）。我将更多地讨论幺半群范畴，并在将来给出完整的定义。

These observations can be formalized by saying that Set (the category of sets) is a monoidal category. It’s a category that’s also a monoid, in the sense that you can multiply objects (here, take their cartesian product). I’ll talk more about monoidal categories, and give the full definition in the future.

在 Haskell 中有一种更通用的方法来定义乘积类型——特别是，正如我们很快就会看到的，当它们与求和类型组合时。它使用带有多个参数的命名构造函数。例如，一对可以定义为：

There is a more general way of defining product types in Haskell — especially, as we’ll see soon, when they are combined with sum types. It uses named constructors with multiple arguments. A pair, for instance, can be defined alternatively as:

data Pair a b = P a b

data Pair a b = P a b

这里，Pair a b是由另外两个类型参数化的类型的名称，a并且b；并且P是数据构造函数的名称。您可以通过将两个类型传递给Pair类型构造函数来定义对类型。您可以通过将两个适当类型的值传递给构造函数来构造对值P。例如，让我们将一个值定义stmt为一对String和Bool：

Here, Pair a b is the name of the type paremeterized by two other types, a and b; and P is the name of the data constructor. You define a pair type by passing two types to the Pair type constructor. You construct a pair value by passing two values of appropriate types to the constructor P. For instance, let’s define a value stmt as a pair of String and Bool:

stmt :: Pair String Bool
stmt = P "This statements is" False

stmt :: Pair String Bool
stmt = P "This statements is" False

第一行是类型声明。它使用类型构造函数Pair，用String和Bool替换 的泛型定义中的a和。第二行通过将具体字符串和具体布尔值传递给数据构造函数来定义实际值。类型构造函数用于构造类型；数据构造函数，构造值。bPairP

The first line is the type declaration. It uses the type constructor Pair, with String and Bool replacing a and the b in the generic definition of Pair. The second line defines the actual value by passing a concrete string and a concrete Boolean to the data constructor P. Type constructors are used to construct types; data constructors, to construct values.

由于类型和数据构造函数的名称空间在 Haskell 中是分开的，因此您经常会看到两者使用相同的名称，如下所示：

Since the name spaces for type and data constructors are separate in Haskell, you will often see the same name used for both, as in:

data Pair a b = Pair a b

data Pair a b = Pair a b

如果您仔细观察，您甚至可能会将内置对类型视为此类声明的变体，其中名称Pair被替换为二元运算符(,)。事实上，您可以(,)像任何其他命名构造函数一样使用并使用前缀表示法创建对：

And if you squint hard enough, you may even view the built-in pair type as a variation on this kind of declaration, where the name Pair is replaced with the binary operator (,). In fact you can use (,) just like any other named constructor and create pairs using prefix notation:

stmt = (,) "This statement is" False

stmt = (,) "This statement is" False

同样，您可以用来(,,)创建三元组，等等。

Similarly, you can use (,,) to create triples, and so on.

您还可以定义特定的命名产品类型，而不是使用通用对或元组，如下所示：

Instead of using generic pairs or tuples, you can also define specific named product types, as in:

data Stmt = Stmt String Bool

data Stmt = Stmt String Bool

String它只是和的乘积Bool，但它有自己的名称和构造函数。这种声明方式的优点是您可以定义许多具有相同内容但不同含义和功能的类型，并且这些类型不能相互替换。

which is just a product of String and Bool, but it’s given its own name and constructor. The advantage of this style of declaration is that you may define many types that have the same content but different meaning and functionality, and which cannot be substituted for each other.

使用元组和多参数构造函数进行编程可能会变得混乱且容易出错——跟踪哪个组件代表什么。通常最好为组件命名。具有命名字段的产品类型在 Haskell 中称为“记录”，struct在 C 中称为“a”。

Programming with tuples and multi-argument constructors can get messy and error prone — keeping track of which component represents what. It’s often preferable to give names to components. A product type with named fields is called a record in Haskell, and a struct in C.

startsWithSymbol :: (String, String, Int) -> Bool
startsWithSymbol (name, symbol, _) = isPrefixOf symbol name

startsWithSymbol :: (String, String, Int) -> Bool
startsWithSymbol (name, symbol, _) = isPrefixOf symbol name

data Element = Element { name         :: String
                       , symbol       :: String
                       , atomicNumber :: Int }

data Element = Element { name         :: String
                       , symbol       :: String
                       , atomicNumber :: Int }

tupleToElem :: (String, String, Int) -> Element
tupleToElem (n, s, a) = Element { name = n
                                , symbol = s
                                , atomicNumber = a }

tupleToElem :: (String, String, Int) -> Element
tupleToElem (n, s, a) = Element { name = n
                                , symbol = s
                                , atomicNumber = a }

elemToTuple :: Element -> (String, String, Int)
elemToTuple e = (name e, symbol e, atomicNumber e)

elemToTuple :: Element -> (String, String, Int)
elemToTuple e = (name e, symbol e, atomicNumber e)

atomicNumber :: Element -> Int

atomicNumber :: Element -> Int

startsWithSymbol :: Element -> Bool
startsWithSymbol e = isPrefixOf (symbol e) (name e)

startsWithSymbol :: Element -> Bool
startsWithSymbol e = isPrefixOf (symbol e) (name e)

startsWithSymbol e = symbol e `isPrefixOf` name e

startsWithSymbol e = symbol e `isPrefixOf` name e

7.2求和类型

7.2 Sum Types

正如集合范畴中的乘积产生乘积类型一样，余积产生和类型。Haskell 中求和类型的规范实现是：

Just as the product in the category of sets gives rise to product types, the coproduct gives rise to sum types. The canonical implementation of a sum type in Haskell is:

data Either a b = Left a | Right b

data Either a b = Left a | Right b

与对一样，Eithers 是可交换的（直到同构），可以嵌套，并且嵌套顺序无关（直到同构）。例如，我们可以定义一个三元组的总和：

And like pairs, Eithers are commutative (up to isomorphism), can be nested, and the nesting order is irrelevant (up to isomorphism). So we can, for instance, define a sum equivalent of a triple:

data OneOfThree a b c = Sinistral a | Medial b | Dextral c

data OneOfThree a b c = Sinistral a | Medial b | Dextral c

等等。

and so on.

事实证明，集合也是一个关于余积的（对称）幺半群范畴。二元运算的作用是由不相交和来扮演的，单位元素的角色是由初始对象来扮演的。就类型而言，我们将Either幺半群算子 和Void，即无人居住的类型，作为它的中性元素。您可以将其视为Either加号，并将Void其视为零。事实上，添加Void到 sum 类型不会改变其内容。例如：

It turns out that Set is also a (symmetric) monoidal category with respect to coproduct. The role of the binary operation is played by the disjoint sum, and the role of the unit element is played by the initial object. In terms of types, we have Either as the monoidal operator and Void, the uninhabited type, as its neutral element. You can think of Either as plus, and Void as zero. Indeed, adding Void to a sum type doesn’t change its content. For instance:

Either a Void

Either a Void

同构于a. 那是因为没有办法构造Right这种类型的版本——没有 type 的值Void。的唯一居民Either a Void是使用Left构造函数构造的，它们只是封装类型的值a。因此，象征性地，a + 0 = a.

is isomorphic to a. That’s because there is no way to construct a Right version of this type — there isn’t a value of type Void. The only inhabitants of Either a Void are constructed using the Left constructors and they simply encapsulate a value of type a. So, symbolically, a + 0 = a.

Sum 类型在 Haskell 中非常常见，但它们的 C++ 等效项、联合或变体则不太常见。这有几个原因。

Sum types are pretty common in Haskell, but their C++ equivalents, unions or variants, are much less common. There are several reasons for that.

首先，最简单的求和类型只是枚举，并且是enum在 C++ 中实现的。相当于 Haskell sum 类型：

First of all, the simplest sum types are just enumerations and are implemented using enum in C++. The equivalent of the Haskell sum type:

data Color = Red | Green | Blue

data Color = Red | Green | Blue

是C++：

is the C++:

enum { Red, Green, Blue };

enum { Red, Green, Blue };

更简单的求和类型：

An even simpler sum type:

data Bool = True | False

data Bool = True | False

是 C++ 中的原语bool。

is the primitive bool in C++.

对值的存在或不存在进行编码的简单求和类型在 C++ 中使用特殊技巧和“不可能”值（如空字符串、负数、空指针等）以不同方式实现。这种可选性（如果有意）在 Haskell 中表达使用Maybe类型：

Simple sum types that encode the presence or absence of a value are variously implemented in C++ using special tricks and “impossible” values, like empty strings, negative numbers, null pointers, etc. This kind of optionality, if deliberate, is expressed in Haskell using the Maybe type:

data Maybe a = Nothing | Just a

data Maybe a = Nothing | Just a

该Maybe类型是两种类型的总和。如果将两个构造函数分成单独的类型，您可以看到这一点。第一个看起来像这样：

The Maybe type is a sum of two types. You can see this if you separate the two constructors into individual types. The first one would look like this:

data NothingType = Nothing

data NothingType = Nothing

它是一个具有一个名为 的值的枚举Nothing。换句话说，它是一个单例，相当于单元类型()。第二部分：

It’s an enumeration with one value called Nothing. In other words, it’s a singleton, which is equivalent to the unit type (). The second part:

data JustType a = Just a

data JustType a = Just a

只是类型的封装a。我们可以编码Maybe为：

is just an encapsulation of the type a. We could have encoded Maybe as:

data Maybe a = Either () a

data Maybe a = Either () a

在 C++ 中，通常使用指针来伪造更复杂的求和类型。指针可以为 null，也可以指向特定类型的值。例如，Haskell 列表类型，可以定义为（递归）求和类型：

More complex sum types are often faked in C++ using pointers. A pointer can be either null, or point to a value of specific type. For instance, a Haskell list type, which can be defined as a (recursive) sum type:

List a = Nil | Cons a (List a)

List a = Nil | Cons a (List a)

可以使用空指针技巧转换为 C++ 来实现空列表：

can be translated to C++ using the null pointer trick to implement the empty list:

template<class A> 
class List {
    Node<A> * _head;
public:
    List() : _head(nullptr) {}  // Nil
    List(A a, List<A> l)        // Cons
      : _head(new Node<A>(a, l))
    {}
};

template<class A> 
class List {
    Node<A> * _head;
public:
    List() : _head(nullptr) {}  // Nil
    List(A a, List<A> l)        // Cons
      : _head(new Node<A>(a, l))
    {}
};

请注意，两个 Haskell 构造函数Nil和Cons被转换为两个List具有类似参数的重载构造函数（无， for Nil；以及值和列表 for Cons）。该类List不需要标记来区分总和类型的两个组件。相反，它使用特殊nullptr值 来_head编码Nil。

Notice that the two Haskell constructors Nil and Cons are translated into two overloaded List constructors with analogous arguments (none, for Nil; and a value and a list for Cons). The List class doesn’t need a tag to distinguish between the two components of the sum type. Instead it uses the special nullptr value for _head to encode Nil.

不过，Haskell 和 C++ 类型之间的主要区别在于 Haskell 数据结构是不可变的。如果使用一个特定的构造函数创建一个对象，该对象将永远记住使用了哪个构造函数以及传递给它的参数。因此，Maybe创建为 的对象Just "energy"永远不会变成Nothing. 同样，空列表将永远为空，并且三个元素的列表将始终具有相同的三个元素。

The main difference, though, between Haskell and C++ types is that Haskell data structures are immutable. If you create an object using one particular constructor, the object will forever remember which constructor was used and what arguments were passed to it. So a Maybe object that was created as Just "energy" will never turn into Nothing. Similarly, an empty list will forever be empty, and a list of three elements will always have the same three elements.

正是这种不变性使得构造可逆。给定一个对象，您始终可以将其拆解成其构造中使用的部件。这种解构是通过模式匹配完成的，并且它重用构造函数作为模式。构造函数参数（如果有）将替换为变量（或其他模式）。

It’s this immutability that makes construction reversible. Given an object, you can always disassemble it down to parts that were used in its construction. This deconstruction is done with pattern matching and it reuses constructors as patterns. Constructor arguments, if any, are replaced with variables (or other patterns).

该List数据类型有两个构造函数，因此任意数据类型的解构List使用与这些构造函数相对应的两种模式。一个匹配空Nil列表，另一个匹配Cons构造列表。例如，下面是 s 上一个简单函数的定义List：

The List data type has two constructors, so the deconstruction of an arbitrary List uses two patterns corresponding to those constructors. One matches the empty Nil list, and the other a Cons-constructed list. For instance, here’s the definition of a simple function on Lists:

maybeTail :: List a -> Maybe (List a)
maybeTail Nil = Nothing
maybeTail (Cons _ t) = Just t

maybeTail :: List a -> Maybe (List a)
maybeTail Nil = Nothing
maybeTail (Cons _ t) = Just t

定义的第一部分maybeTail使用Nil构造函数作为模式并返回Nothing。第二部分使用Cons构造函数作为模式。它用通配符替换第一个构造函数参数，因为我们对它不感兴趣。第二个参数 toCons绑定到变量t（我将这些东西称为变量，尽管严格来说，它们永远不会改变：一旦绑定到表达式，变量就永远不会改变）。返回值为Just t. 现在，根据您的List创建方式，它将匹配其中一个子句。如果它是使用 创建的Cons，则将检索传递给它的两个参数（并丢弃第一个参数）。

The first part of the definition of maybeTail uses the Nil constructor as pattern and returns Nothing. The second part uses the Cons constructor as pattern. It replaces the first constructor argument with a wildcard, because we are not interested in it. The second argument to Cons is bound to the variable t (I will call these things variables even though, strictly speaking, they never vary: once bound to an expression, a variable never changes). The return value is Just t. Now, depending on how your List was created, it will match one of the clauses. If it was created using Cons, the two arguments that were passed to it will be retrieved (and the first discarded).

更复杂的求和类型是使用多态类层次结构在 C++ 中实现的。具有共同祖先的类族可以被理解为一种变体类型，其中vtable充当隐藏标记。在 Haskell 中，通过构造函数上的模式匹配以及调用专门的代码来完成，而在 C++ 中，则通过根据 vtable 指针分派对虚拟函数的调用来完成。

Even more elaborate sum types are implemented in C++ using polymorphic class hierarchies. A family of classes with a common ancestor may be understood as one variant type, in which the vtable serves as a hidden tag. What in Haskell would be done by pattern matching on the constructor, and by calling specialized code, in C++ is accomplished by dispatching a call to a virtual function based on the vtable pointer.

union由于联合中的内容受到严格限制，因此在 C++ 中很少会看到用作求和类型。您甚至不能将 a 放入std::string联合中，因为它有一个复制构造函数。

You will rarely see union used as a sum type in C++ because of severe limitations on what can go into a union. You can’t even put a std::string into a union because it has a copy constructor.

7.3类型代数

7.3 Algebra of Types

单独来看，乘积和求和类型可用于定义各种有用的数据结构，但真正的优势来自于将两者结合起来。我们再次调用构图的力量。

Taken separately, product and sum types can be used to define a variety of useful data structures, but the real strength comes from combining the two. Once again we are invoking the power of composition.

让我们总结一下到目前为止我们所发现的内容。我们已经看到了类型系统底层的两种可交换幺半群结构：我们将和类型作为Void中性元素，将乘积类型以单位类型()作为中性元素。我们希望将它们视为类似于加法和乘法。在这个类比中，Void对应于零，单位 ,()对应于一。

Let’s summarize what we’ve discovered so far. We’ve seen two commutative monoidal structures underlying the type system: We have the sum types with Void as the neutral element, and the product types with the unit type, (), as the neutral element. We’d like to think of them as analogous to addition and multiplication. In this analogy, Void would correspond to zero, and unit, (), to one.

让我们看看我们可以将这个类比延伸到什么程度。例如，乘以零会得到零吗？换句话说，具有一个组件的产品类型是否与 是Void同构的Void？例如，是否可以创建一对，例如Int和Void？

Let’s see how far we can stretch this analogy. For instance, does multiplication by zero give zero? In other words, is a product type with one component being Void isomorphic to Void? For example, is it possible to create a pair of, say Int and Void?

要创建一对，您需要两个值。尽管您可以轻松得出整数，但没有 类型的值Void。因此，对于任何类型a，该类型(a, Void)都是无人居住的——没有值——因此等价于Void。换句话说，a*0 = 0.

To create a pair you need two values. Although you can easily come up with an integer, there is no value of type Void. Therefore, for any type a, the type (a, Void) is uninhabited — has no values — and is therefore equivalent to Void. In other words, a*0 = 0.

连接加法和乘法的另一件事是分配律：

Another thing that links addition and multiplication is the distributive property:

a * (b + c) = a * b + a * c

a * (b + c) = a * b + a * c

它也适用于乘积和总和类型吗？是的，确实如此——像往常一样，直到同构为止。左侧对应于类型：

Does it also hold for product and sum types? Yes, it does — up to isomorphisms, as usual. The left hand side corresponds to the type:

(a, Either b c)

(a, Either b c)

右侧对应于以下类型：

and the right hand side corresponds to the type:

Either (a, b) (a, c)

Either (a, b) (a, c)

这是以一种方式转换它们的函数：

Here’s the function that converts them one way:

prodToSum :: (a, Either b c) -> Either (a, b) (a, c)
prodToSum (x, e) = 
    case e of
      Left  y -> Left  (x, y)
      Right z -> Right (x, z)

prodToSum :: (a, Either b c) -> Either (a, b) (a, c)
prodToSum (x, e) = 
    case e of
      Left  y -> Left  (x, y)
      Right z -> Right (x, z)

这是一个相反的情况：

and here’s one that goes the other way:

sumToProd :: Either (a, b) (a, c) -> (a, Either b c)
sumToProd e = 
    case e of
      Left  (x, y) -> (x, Left  y)
      Right (x, z) -> (x, Right z)

sumToProd :: Either (a, b) (a, c) -> (a, Either b c)
sumToProd e = 
    case e of
      Left  (x, y) -> (x, Left  y)
      Right (x, z) -> (x, Right z)

该case of语句用于函数内部的模式匹配。每个模式后面都有一个箭头和模式匹配时要计算的表达式。例如，如果您prodToSum使用以下值进行调用：

The case of statement is used for pattern matching inside functions. Each pattern is followed by an arrow and the expression to be evaluated when the pattern matches. For instance, if you call prodToSum with the value:

prod1 :: (Int, Either String Float)
prod1 = (2, Left "Hi!")

prod1 :: (Int, Either String Float)
prod1 = (2, Left "Hi!")

in将等于e。它将匹配模式，替换。由于已与 匹配，因此该子句的结果以及整个函数将如预期的那样为 。case e ofLeft "Hi!"Left y"Hi!"yx2case ofLeft (2, "Hi!")

the e in case e of will be equal to Left "Hi!". It will match the pattern Left y, substituting "Hi!" for y. Since the x has already been matched to 2, the result of the case of clause, and the whole function, will be Left (2, "Hi!"), as expected.

我不会证明这两个函数是互逆的，但如果你仔细想想，它们一定是互逆的！他们只是简单地重新打包两个数据结构的内容。这是相同的数据，只是格式不同。

I’m not going to prove that these two functions are the inverse of each other, but if you think about it, they must be! They are just trivially re-packing the contents of the two data structures. It’s the same data, only different format.

数学家给这样两个交织在一起的幺半群起了一个名字：它被称为半环。它不是一个完整的环，因为我们无法定义类型的减法。这就是为什么半环有时被称为rig ，它是“没有n的环”（负数）的双关语。但除此之外，我们还可以通过将有关形成环的自然数的语句转换为有关类型的语句来获得很多帮助。这是一个翻译表，其中包含一些有趣的条目：

Mathematicians have a name for such two intertwined monoids: it’s called a semiring. It’s not a full ring, because we can’t define subtraction of types. That’s why a semiring is sometimes called a rig, which is a pun on “ring without an n” (negative). But barring that, we can get a lot of mileage from translating statements about, say, natural numbers, which form a ring, to statements about types. Here’s a translation table with some entries of interest:

列表类型非常有趣，因为它被定义为方程的解。我们定义的类型出现在等式两边：

The list type is quite interesting, because it’s defined as a solution to an equation. The type we are defining appears on both sides of the equation:

List a = Nil | Cons a (List a)

List a = Nil | Cons a (List a)

如果我们进行通常的替换，并用 替换List a，x我们得到等式：

If we do our usual substitutions, and also replace List a with x, we get the equation:

x = 1 + a * x

x = 1 + a * x

我们无法使用传统的代数方法来解决它，因为我们无法对类型进行减法或除法。但我们可以尝试一系列替换，其中我们不断将x右侧替换为(1 + a*x), 并使用分配律。这导致了以下系列：

We can’t solve it using traditional algebraic methods because we can’t subtract or divide types. But we can try a series of substitutions, where we keep replacing x on the right hand side with (1 + a*x), and use the distributive property. This leads to the following series:

x = 1 + a*x
x = 1 + a*(1 + a*x) = 1 + a + a*a*x
x = 1 + a + a*a*(1 + a*x) = 1 + a + a*a + a*a*a*x
...
x = 1 + a + a*a + a*a*a + a*a*a*a...

x = 1 + a*x
x = 1 + a*(1 + a*x) = 1 + a + a*a*x
x = 1 + a + a*a*(1 + a*x) = 1 + a + a*a + a*a*a*x
...
x = 1 + a + a*a + a*a*a + a*a*a*a...

我们最终得到乘积（元组）的无限和，可以将其解释为：列表要么为空，要么为空1。或单身人士，a; 或一对，a*a；或三元组，a*a*a；等等……嗯，这正是列表的含义——一串as！

We end up with an infinite sum of products (tuples), which can be interpreted as: A list is either empty, 1; or a singleton, a; or a pair, a*a; or a triple, a*a*a; etc… Well, that’s exactly what a list is — a string of as!

列表的含义远不止于此，在了解函子和不动点之后，我们将回到列表和其他递归数据结构。

There’s much more to lists than that, and we’ll come back to them and other recursive data structures after we learn about functors and fixed points.

用符号变量求解方程——这就是代数！这就是这些类型的名称：代数数据类型。

Solving equations with symbolic variables — that’s algebra! It’s what gives these types their name: algebraic data types.

最后，我应该提到类型代数的一个非常重要的解释。a请注意，两种类型和的乘积b必须同时包含 type 的值a 和type 的值b，这意味着两种类型都必须存在。另一方面，两种类型的总和包含 type 的值a 或type 的值b，因此只要其中一个存在就足够了。逻辑and和or也形成一个半环，它也可以映射到类型论中：

Finally, I should mention one very important interpretation of the algebra of types. Notice that a product of two types a and b must contain both a value of type a and a value of type b, which means both types must be inhabited. A sum of two types, on the other hand, contains either a value of type a or a value of type b, so it’s enough if one of them is inhabited. Logical and and or also form a semiring, and it too can be mapped into type theory:

这个类比更深入，是逻辑和类型理论之间的库里-霍华德同构的基础。当我们讨论函数类型时，我们会回到它。

This analogy goes deeper, and is the basis of the Curry-Howard isomorphism between logic and type theory. We’ll come back to it when we talk about function types.

7.4挑战

7.4 Challenges

1. Maybe a证明和之间的同构Either () a。
2. Show the isomorphism between Maybe a and Either () a.

3. 这是 Haskell 中定义的 sum 类型：

   data Shape = Circle Float
              | Rect Float Float

   当我们想要定义一个作用于areaa 的函数时Shape，我们通过对两个构造函数进行模式匹配来实现：

   area :: Shape -> Float
   area (Circle r) = pi * r * r
   area (Rect d h) = d * h

   在 C++ 或 Java 中实现Shape为接口并创建两个类：Circle和Rect。area作为虚函数实现。

4. Here’s a sum type defined in Haskell:

   data Shape = Circle Float
              | Rect Float Float

   When we want to define a function like area that acts on a Shape, we do it by pattern matching on the two constructors:

   area :: Shape -> Float
   area (Circle r) = pi * r * r
   area (Rect d h) = d * h

   Implement Shape in C++ or Java as an interface and create two classes: Circle and Rect. Implement area as a virtual function.

5. 继续前面的示例：我们可以轻松添加一个circ计算 a 周长的新函数Shape。我们可以在不触及 的定义的情况下做到这一点Shape：

   circ :: Shape -> Float
   circ (Circle r) = 2.0 * pi * r
   circ (Rect d h) = 2.0 * (d + h)

   添加circ到您的 C++ 或 Java 实现中。您必须接触原始代码的哪些部分？

6. Continuing with the previous example: We can easily add a new function circ that calculates the circumference of a Shape. We can do it without touching the definition of Shape:

   circ :: Shape -> Float
   circ (Circle r) = 2.0 * pi * r
   circ (Rect d h) = 2.0 * (d + h)

   Add circ to your C++ or Java implementation. What parts of the original code did you have to touch?

7. 进一步继续：添加新形状 ,Square并Shape进行所有必要的更新。在 Haskell 中与 C++ 或 Java 相比，你必须接触哪些代码？（即使您不是 Haskell 程序员，修改也应该非常明显。）
8. Continuing further: Add a new shape, Square, to Shape and make all the necessary updates. What code did you have to touch in Haskell vs. C++ or Java? (Even if you’re not a Haskell programmer, the modifications should be pretty obvious.)
9. 显示这a + a = 2 * a适用于类型（直至同构）。请记住，根据我们的翻译表，2对应于。Bool
10. Show that a + a = 2 * a holds for types (up to isomorphism). Remember that 2 corresponds to Bool, according to our translation table.

8.1编程中的函子

8.1 Functors in Programming

让我们脚踏实地地谈谈编程吧。我们有自己的类型和功能范畴。我们可以讨论将这个范畴映射到自身的函子——这样的函子称为endofunctor。那么类型范畴中的内函子是什么？首先，它将类型映射到类型。我们已经看到过此类映射的示例，但也许没有意识到它们就是这样。我正在谈论由其他类型参数化的类型的定义。让我们看几个例子。

Let’s get down to earth and talk about programming. We have our category of types and functions. We can talk about functors that map this category into itself — such functors are called endofunctors. So what’s an endofunctor in the category of types? First of all, it maps types to types. We’ve seen examples of such mappings, maybe without realizing that they were just that. I’m talking about definitions of types that were parameterized by other types. Let’s see a few examples.

data Maybe a = Nothing | Just a

data Maybe a = Nothing | Just a

f :: a -> b

f :: a -> b

f’ :: Maybe a -> Maybe b
f’ Nothing = Nothing
f’ (Just x) = Just (f x)

f’ :: Maybe a -> Maybe b
f’ Nothing = Nothing
f’ (Just x) = Just (f x)

fmap :: (a -> b) -> (Maybe a -> Maybe b)

fmap :: (a -> b) -> (Maybe a -> Maybe b)

fmap :: (a -> b) -> Maybe a -> Maybe b

fmap :: (a -> b) -> Maybe a -> Maybe b

fmap _ Nothing = Nothing
fmap f (Just x) = Just (f x)

fmap _ Nothing = Nothing
fmap f (Just x) = Just (f x)

id x = x

id x = x

fmap id = id

fmap id = id

  fmap id Nothing 
= { definition of fmap }
  Nothing 
= { definition of id }
  id Nothing

  fmap id Nothing 
= { definition of fmap }
  Nothing 
= { definition of id }
  id Nothing

  fmap id (Just x) 
= { definition of fmap }
  Just (id x) 
= { definition of id }
  Just x
= { definition of id }
  id (Just x)

  fmap id (Just x) 
= { definition of fmap }
  Just (id x) 
= { definition of id }
  Just x
= { definition of id }
  id (Just x)

fmap (g . f) = fmap g . fmap f

fmap (g . f) = fmap g . fmap f

  fmap (g . f) Nothing 
= { definition of fmap }
  Nothing 
= { definition of fmap }
  fmap g Nothing
= { definition of fmap }
  fmap g (fmap f Nothing)

  fmap (g . f) Nothing 
= { definition of fmap }
  Nothing 
= { definition of fmap }
  fmap g Nothing
= { definition of fmap }
  fmap g (fmap f Nothing)

  fmap (g . f) (Just x)
= { definition of fmap }
  Just ((g . f) x)
= { definition of composition }
  Just (g (f x))
= { definition of fmap }
  fmap g (Just (f x))
= { definition of fmap }
  fmap g (fmap f (Just x))
= { definition of composition }
  (fmap g . fmap f) (Just x)

  fmap (g . f) (Just x)
= { definition of fmap }
  Just ((g . f) x)
= { definition of composition }
  Just (g (f x))
= { definition of fmap }
  fmap g (Just (f x))
= { definition of fmap }
  fmap g (fmap f (Just x))
= { definition of composition }
  (fmap g . fmap f) (Just x)

int square(int x) {
    return x * x;
}

int counter() {
    static int c = 0;
    return c++;
}

double y = square(counter());

int square(int x) {
    return x * x;
}

int counter() {
    static int c = 0;
    return c++;
}

double y = square(counter());

double y = counter() * counter();

double y = counter() * counter();

template<class T>
class optional {
    bool _isValid; // the tag
    T    _v;
public:
    optional()    : _isValid(false) {}         // Nothing
    optional(T x) : _isValid(true) , _v(x) {}  // Just
    bool isValid() const { return _isValid; }
    T val() const { return _v; }
};

template<class T>
class optional {
    bool _isValid; // the tag
    T    _v;
public:
    optional()    : _isValid(false) {}         // Nothing
    optional(T x) : _isValid(true) , _v(x) {}  // Just
    bool isValid() const { return _isValid; }
    T val() const { return _v; }
};

template<class A, class B>
std::function<optional<B>(optional<A>)> 
fmap(std::function<B(A)> f) 
{
    return [f](optional<A> opt) {
        if (!opt.isValid())
            return optional<B>{};
        else
            return optional<B>{ f(opt.val()) };
    };
}

template<class A, class B>
std::function<optional<B>(optional<A>)> 
fmap(std::function<B(A)> f) 
{
    return [f](optional<A> opt) {
        if (!opt.isValid())
            return optional<B>{};
        else
            return optional<B>{ f(opt.val()) };
    };
}

template<class A, class B>
optional<B> fmap(std::function<B(A)> f, optional<A> opt) {
    if (!opt.isValid())
        return optional<B>{};
    else
        return optional<B>{ f(opt.val()) };
}

template<class A, class B>
optional<B> fmap(std::function<B(A)> f, optional<A> opt) {
    if (!opt.isValid())
        return optional<B>{};
    else
        return optional<B>{ f(opt.val()) };
}

auto g = fmap(f);

auto g = fmap(f);

class Eq a where
    (==) :: a -> a -> Bool

class Eq a where
    (==) :: a -> a -> Bool

data Point = Pt Float Float

data Point = Pt Float Float

instance Eq Point where
    (Pt x y) == (Pt x' y') = x == x' && y == y'

instance Eq Point where
    (Pt x y) == (Pt x' y') = x == x' && y == y'

class Functor f where
    fmap :: (a -> b) -> f a -> f b

class Functor f where
    fmap :: (a -> b) -> f a -> f b

instance Functor Maybe where
    fmap _ Nothing = Nothing
    fmap f (Just x) = Just (f x)

instance Functor Maybe where
    fmap _ Nothing = Nothing
    fmap f (Just x) = Just (f x)

template<template<class> F, class A, class B>
  F<B> fmap(std::function<B(A)>, F<A>);

template<template<class> F, class A, class B>
  F<B> fmap(std::function<B(A)>, F<A>);

template<class A, class B>
  optional<B> fmap<optional>(std::function<B(A)> f, optional<A> opt)

template<class A, class B>
  optional<B> fmap<optional>(std::function<B(A)> f, optional<A> opt)

template<class A, class B>
optional<B> fmap(std::function<B(A)> f, optional<A> opt) 
{
    if (!opt.isValid())
        return optional<B>{};
    else
        return optional<B>{ f(opt.val()) };
}

template<class A, class B>
optional<B> fmap(std::function<B(A)> f, optional<A> opt) 
{
    if (!opt.isValid())
        return optional<B>{};
    else
        return optional<B>{ f(opt.val()) };
}

data List a = Nil | Cons a (List a)

data List a = Nil | Cons a (List a)

fmap :: (a -> b) -> (List a -> List b)

fmap :: (a -> b) -> (List a -> List b)

fmap f (Cons x t) = Cons (f x) (fmap f t)

fmap f (Cons x t) = Cons (f x) (fmap f t)

instance Functor List where
    fmap _ Nil = Nil
    fmap f (Cons x t) = Cons (f x) (fmap f t)

instance Functor List where
    fmap _ Nil = Nil
    fmap f (Cons x t) = Cons (f x) (fmap f t)

template<class A, class B>
std::vector<B> fmap(std::function<B(A)> f, std::vector<A> v)
{
    std::vector<B> w;
    std::transform( std::begin(v)
                  , std::end(v)
                  , std::back_inserter(w)
                  , f);
    return w;
}

template<class A, class B>
std::vector<B> fmap(std::function<B(A)> f, std::vector<A> v)
{
    std::vector<B> w;
    std::transform( std::begin(v)
                  , std::end(v)
                  , std::back_inserter(w)
                  , f);
    return w;
}

std::vector<int> v{ 1, 2, 3, 4 };
auto w = fmap([](int i) { return i*i; }, v);
std::copy( std::begin(w)
         , std::end(w)
         , std::ostream_iterator(std::cout, ", "));

std::vector<int> v{ 1, 2, 3, 4 };
auto w = fmap([](int i) { return i*i; }, v);
std::copy( std::begin(w)
         , std::end(w)
         , std::ostream_iterator(std::cout, ", "));

(->) a b

(->) a b

(->) a

(->) a

fmap :: (a -> b) -> (r -> a) -> (r -> b)

fmap :: (a -> b) -> (r -> a) -> (r -> b)

instance Functor ((->) r) where
    fmap f g = f . g

instance Functor ((->) r) where
    fmap f g = f . g

fmap f g = (.) f g

fmap f g = (.) f g

fmap = (.)

fmap = (.)

8.2作为容器的函子

8.2 Functors as Containers

我们已经在编程语言中看到了一些函子的示例，它们定义了通用容器，或者至少是包含其参数化类型的某些值的对象。读者函子似乎是一个异常值，因为我们不将函数视为数据。但我们已经看到纯函数可以被记忆，并且函数执行可以变成查表。表格是数据。相反，由于 Haskell 的惰性，传统容器（如列表）实际上可能被实现为函数。例如，考虑一个无限的自然数列表，它可以紧凑地定义为：

We’ve seen some examples of functors in programming languages that define general-purpose containers, or at least objects that contain some value of the type they are parameterized over. The reader functor seems to be an outlier, because we don’t think of functions as data. But we’ve seen that pure functions can be memoized, and function execution can be turned into table lookup. Tables are data. Conversely, because of Haskell’s laziness, a traditional container, like a list, may actually be implemented as a function. Consider, for instance, an infinite list of natural numbers, which can be compactly defined as:

nats :: [Integer]
nats = [1..]

nats :: [Integer]
nats = [1..]

第一行中，一对方括号是 Haskell 的内置列表类型构造函数。在第二行中，方括号用于创建列表文字。显然，这样的无限列表无法存储在内存中。Integer编译器将其实现为按需生成 s 的函数。Haskell 有效地模糊了数据和代码之间的区别。列表可以被视为函数，函数可以被视为将参数映射到结果的表。如果函数的域是有限的并且不是太大，则后者甚至可以是实用的。然而，实现为表查找是不切实际的strlen，因为存在无限多个不同的字符串。作为程序员，我们不喜欢无穷大，但在范畴论中，你学会把无穷大当早餐吃。无论是所有字符串的集合，还是宇宙所有可能状态（过去、现在和未来）的集合 - 我们都可以处理它！因此，我喜欢将函子对象（由 endofunctor 生成的类型的对象）视为包含参数化类型的一个或多个值，即使这些值实际上并不存在于其中。函子的一个例子是 C++ std::future，它可能在某个时刻包含一个值，但不能保证它会包含一个值；如果你想访问它，你可以阻塞等待另一个线程完成执行。另一个例子是 HaskellIO对象，它可能包含用户输入，或者带有“Hello World!”的宇宙的未来版本。显示在监视器上。根据这种解释，函子对象可能包含其参数化类型的一个或多个值。或者它可能包含生成这些值的方法。我们根本不关心能否访问这些值——这完全是可选的，并且超出了函子的范围。我们感兴趣的是能够使用函数来操纵这些值。如果可以访问这些值，那么我们应该能够看到此操作的结果。如果他们不能，那么我们所关心的是操作是否正确组成，并且使用恒等函数进行的操作不会改变任何东西。只是为了向您展示我们有多么不关心能否访问函子对象内的值，这里有一个完全忽略其参数的类型构造函数a：

In the first line, a pair of square brackets is the Haskell’s built-in type constructor for lists. In the second line, square brackets are used to create a list literal. Obviously, an infinite list like this cannot be stored in memory. The compiler implements it as a function that generates Integers on demand. Haskell effectively blurs the distinction between data and code. A list could be considered a function, and a function could be considered a table that maps arguments to results. The latter can even be practical if the domain of the function is finite and not too large. It would not be practical, however, to implement strlen as table lookup, because there are infinitely many different strings. As programmers, we don’t like infinities, but in category theory you learn to eat infinities for breakfast. Whether it’s a set of all strings or a collection of all possible states of the Universe, past, present, and future — we can deal with it! So I like to think of the functor object (an object of the type generated by an endofunctor) as containing a value or values of the type over which it is parameterized, even if these values are not physically present there. One example of a functor is a C++ std::future, which may at some point contain a value, but it’s not guaranteed it will; and if you want to access it, you may block waiting for another thread to finish execution. Another example is a Haskell IO object, which may contain user input, or the future versions of our Universe with “Hello World!” displayed on the monitor. According to this interpretation, a functor object is something that may contain a value or values of the type it’s parameterized upon. Or it may contain a recipe for generating those values. We are not at all concerned about being able to access the values — that’s totally optional, and outside of the scope of the functor. All we are interested in is to be able to manipulate those values using functions. If the values can be accessed, then we should be able to see the results of this manipulation. If they can’t, then all we care about is that the manipulations compose correctly and that the manipulation with an identity function doesn’t change anything. Just to show you how much we don’t care about being able to access the values inside a functor object, here’s a type constructor that ignores completely its argument a:

data Const c a = Const c

data Const c a = Const c

类型构造函数Const采用两种类型，c和a。就像我们对箭头构造函数所做的那样，我们将部分应用它来创建一个函子。数据构造函数（也称为Const）仅采用一个类型的值c。它不依赖于a. fmap该类型构造函数的类型是：

The Const type constructor takes two types, c and a. Just like we did with the arrow constructor, we are going to partially apply it to create a functor. The data constructor (also called Const) takes just one value of type c. It has no dependence on a. The type of fmap for this type constructor is:

fmap :: (a -> b) -> Const c a -> Const c b

fmap :: (a -> b) -> Const c a -> Const c b

因为函子忽略它的类型参数，所以 的实现fmap可以自由地忽略它的函数参数——该函数没有任何可操作的：

Because the functor ignores its type argument, the implementation of fmap is free to ignore its function argument — the function has nothing to act upon:

instance Functor (Const c) where
    fmap _ (Const v) = Const v

instance Functor (Const c) where
    fmap _ (Const v) = Const v

这在 C++ 中可能会更清楚一些（我从来没想过我会说出这些话！），其中类型参数（编译时）和值（运行时）之间有更明显的区别：

This might be a little clearer in C++ (I never thought I would utter those words!), where there is a stronger distinction between type arguments — which are compile-time — and values, which are run-time:

template<class C, class A>
struct Const {
    Const(C v) : _v(v) {}
    C _v;
};

template<class C, class A>
struct Const {
    Const(C v) : _v(v) {}
    C _v;
};

的 C++ 实现fmap也会忽略函数参数，并且本质上会重新转换Const参数而不更改其值：

The C++ implementation of fmap also ignores the function argument and essentially re-casts the Const argument without changing its value:

template<class C, class A, class B>
Const<C, B> fmap(std::function<B(A)> f, Const<C, A> c) {
    return Const<C, B>{c._v};
}

template<class C, class A, class B>
Const<C, B> fmap(std::function<B(A)> f, Const<C, A> c) {
    return Const<C, B>{c._v};
}

尽管函子很奇怪，但它Const在许多构造中发挥着重要作用。在范畴论中，它是我之前提到的 Δ _c函子的一个特例——黑洞的内函子情况。将来我们会看到更多这样的情况。

Despite its weirdness, the Const functor plays an important role in many constructions. In category theory, it’s a special case of the Δ_c functor I mentioned earlier — the endo-functor case of a black hole. We’ll be seeing more of it it in the future.

8.3函子组成

8.3 Functor Composition

说服自己范畴之间的函子组合并不难，就像集合之间的函数组合一样。两个函子的组合，当作用于对象时，只是它们各自对象映射的组合；当作用于态射时也是如此。在跳过两个函子之后，恒等态射最终成为恒等态射，而态射的组合最终成为态射的组合。确实没有什么太多的。特别是，构造内函子很容易。还记得这个功能maybeTail吗？我将使用 Haskell 的内置列表实现重写它：

It’s not hard to convince yourself that functors between categories compose, just like functions between sets compose. A composition of two functors, when acting on objects, is just the composition of their respective object mappings; and similarly when acting on morphisms. After jumping through two functors, identity morphisms end up as identity morphisms, and compositions of morphisms finish up as compositions of morphisms. There’s really nothing much to it. In particular, it’s easy to compose endofunctors. Remember the function maybeTail? I’ll rewrite it using the Haskell’s built in implementation of lists:

maybeTail :: [a] -> Maybe [a]
maybeTail [] = Nothing
maybeTail (x:xs) = Just xs

maybeTail :: [a] -> Maybe [a]
maybeTail [] = Nothing
maybeTail (x:xs) = Just xs

（我们过去调用的空列表构造函数Nil被空方括号对替换[]。Cons构造函数被中缀运算符:（冒号）替换。） 的结果maybeTail是由两个函子组成的类型，Maybe并且[]，上a. 这些函子中的每一个都配备了自己的 版本fmap，但是如果我们想将某些函数应用于f组合的内容：列表，该怎么办Maybe？我们必须突破两层函子。我们可以利用fmap外来突破Maybe。但我们不能只发送f内部Maybe，因为它f不适用于列表。我们必须发送(fmap f)对内部列表进行操作。例如，让我们看看如何对Maybe整数列表的元素进行平方：

(The empty list constructor that we used to call Nil is replaced with the empty pair of square brackets []. The Cons constructor is replaced with the infix operator : (colon).) The result of maybeTail is of a type that’s a composition of two functors, Maybe and [], acting on a. Each of these functors is equipped with its own version of fmap, but what if we want to apply some function f to the contents of the composite: a Maybe list? We have to break through two layers of functors. We can use fmap to break through the outer Maybe. But we can’t just send f inside Maybe because f doesn’t work on lists. We have to send (fmap f) to operate on the inner list. For instance, let’s see how we can square the elements of a Maybe list of integers:

square x = x * x

mis :: Maybe [Int]
mis = Just [1, 2, 3]

mis2 = fmap (fmap square) mis

square x = x * x

mis :: Maybe [Int]
mis = Just [1, 2, 3]

mis2 = fmap (fmap square) mis

编译器在分析类型后会发现，对于外部类型fmap，它应该使用实例的实现Maybe，而对于内部类型，它应该使用列表函子实现。上面的代码可以重写为：

The compiler, after analyzing the types, will figure out that, for the outer fmap, it should use the implementation from the Maybe instance, and for the inner one, the list functor implementation. It may not be immediately obvious that the above code may be rewritten as:

mis2 = (fmap . fmap) square mis

mis2 = (fmap . fmap) square mis

但请记住，这fmap可能被视为只有一个参数的函数：

But remember that fmap may be considered a function of just one argument:

fmap :: (a -> b) -> (f a -> f b)

fmap :: (a -> b) -> (f a -> f b)

在我们的例子中，第二个fmap作为(fmap . fmap)它的参数：

In our case, the second fmap in (fmap . fmap) takes as its argument:

square :: Int -> Int

square :: Int -> Int

并返回一个类型的函数：

and returns a function of the type:

[Int] -> [Int]

[Int] -> [Int]

然后第一个fmap函数接受该函数并返回一个函数：

The first fmap then takes that function and returns a function:

Maybe [Int] -> Maybe [Int]

Maybe [Int] -> Maybe [Int]

最后，将该函数应用于mis. 因此两个函子的复合是一个函子，其fmap是对应的 s 的复合fmap。回到范畴论：很明显，函子组合是结合的（对象的映射是结合的，态射的映射是结合的）。每个范畴中还有一个平凡的恒等函子：它将每个对象映射到自身，并将每个态射映射到自身。因此，函子在某些范畴中具有与态射相同的性质。但那会是什么范畴呢？它必须是一个范畴，其中对象是范畴，态射是函子。这是范畴的范畴。但是所有范畴的范畴必须包含其自身，我们就会陷入同样的​​悖论，使所有集合的集合变得不可能。然而，所有小范畴中有一个范畴称为Cat（它很大，因此它不能成为其自身的成员）。小范畴是指对象形成一个集合，而不是大于集合的对象。请注意，在范畴论中，即使是无限不可数的集合也被认为是“小”。我想我应该提到这些事情，因为我发现我们能够识别在多个抽象层次上重复的相同结构非常令人惊奇。稍后我们将看到函子也形成范畴。

Finally, that function is applied to mis. So the composition of two functors is a functor whose fmap is the composition of the corresponding fmaps. Going back to category theory: It’s pretty obvious that functor composition is associative (the mapping of objects is associative, and the mapping of morphisms is associative). And there is also a trivial identity functor in every category: it maps every object to itself, and every morphism to itself. So functors have all the same properties as morphisms in some category. But what category would that be? It would have to be a category in which objects are categories and morphisms are functors. It’s a category of categories. But a category of all categories would have to include itself, and we would get into the same kinds of paradoxes that made the set of all sets impossible. There is, however, a category of all small categories called Cat (which is big, so it can’t be a member of itself). A small category is one in which objects form a set, as opposed to something larger than a set. Mind you, in category theory, even an infinite uncountable set is considered “small.” I thought I’d mention these things because I find it pretty amazing that we can recognize the same structures repeating themselves at many levels of abstraction. We’ll see later that functors form categories as well.

8.4挑战

8.4 Challenges

1. 我们可以Maybe通过定义将类型构造函数转换为函子吗：

   fmap _ _ = Nothing

   它忽略了它的两个参数？（提示：检查函子定律。）

2. Can we turn the Maybe type constructor into a functor by defining:

   fmap _ _ = Nothing

   which ignores both of its arguments? (Hint: Check the functor laws.)

3. 证明读者函子的函子定律。提示：这真的很简单。
4. Prove functor laws for the reader functor. Hint: it’s really simple.
5. 用你第二喜欢的语言（当然第一个是 Haskell）实现 reader 函子。
6. Implement the reader functor in your second favorite language (the first being Haskell, of course).
7. 证明列表函子的函子定律。假设这些定律对于您要应用的列表的尾部部分是正确的（换句话说，使用归纳法）。
8. Prove the functor laws for the list functor. Assume that the laws are true for the tail part of the list you’re applying it to (in other words, use induction).

8.5致谢

8.5 Acknowledgments

Gershom Bazerman 很友善地继续审查这些帖子。我很感谢他的耐心和洞察力。

Gershom Bazerman is kind enough to keep reviewing these posts. I’m grateful for his patience and insight.

9.1双函子

9.1 Bifunctors

由于函子是Cat（范畴的范畴）中的态射，因此许多关于态射（尤其是函数）的直觉也适用于函子。例如，就像您可以拥有两个参数的函数一样，您也可以拥有两个参数的函子或bifunctor。在对象上，双函子将每对对象（一个来自范畴 C，一个来自范畴 D）映射到范畴 E 中的一个对象。请注意，这只是说它是从范畴 C×D 到 E 的笛卡尔积的映射。

Since functors are morphisms in Cat (the category of categories), a lot of intuitions about morphisms — and functions in particular — apply to functors as well. For instance, just like you can have a function of two arguments, you can have a functor of two arguments, or a bifunctor. On objects, a bifunctor maps every pair of objects, one from category C, and one from category D, to an object in category E. Notice that this is just saying that it’s a mapping from a cartesian product of categories C×D to E.

这非常简单。但函子性意味着双函子也必须映射态射。不过，这一次，它必须将一对态射（一个来自 C，一个来自 D）映射到 E 中的态射。

That’s pretty straightforward. But functoriality means that a bifunctor has to map morphisms as well. This time, though, it must map a pair of morphisms, one from C and one from D, to a morphism in E.

同样，一对态射只是乘积范畴 C×D 中的一个态射。我们将范畴的笛卡尔积中的态射定义为从一对对象到另一对对象的一对态射。这些态射对可以用显而易见的方式组成：

Again, a pair of morphisms is just a single morphism in the product category C×D. We define a morphism in a cartesian product of categories as a pair of morphisms which goes from one pair of objects to another pair of objects. These pairs of morphisms can be composed in the obvious way:

(f, g) ∘ (f', g') = (f ∘ f', g ∘ g')

(f, g) ∘ (f', g') = (f ∘ f', g ∘ g')

该组合是结合的并且具有恒等性——一对恒等态射(id, id)。所以范畴的笛卡尔积确实是一个范畴。

The composition is associative and it has an identity — a pair of identity morphisms (id, id). So a cartesian product of categories is indeed a category.

但考虑双函子的一种更简单的方法是，它们在两个参数中都是函子。因此，不必将函子定律（结合性和恒等性保留）从函子翻译为双函子，只需针对每个参数单独检查它们就足够了。如果您有从一对范畴到第三个范畴的映射，并且您分别证明它在每个参数中都是函子（即，保持另一个参数不变），那么该映射将自动成为双函子。我所说的函子是指它像诚实函子一样作用于态射。

But an easier way to think about bifunctors is that they are functors in both arguments. So instead of translating functorial laws — associativity and identity preservation — from functors to bifunctors, it’s enough to check them separately for each argument. If you have a mapping from a pair of categories to a third category, and you prove that it is functorial in each argument separately (i.e., keeping the other argument constant), then the mapping is automatically a bifunctor. By functorial I mean that it acts on morphisms like an honest functor.

让我们在 Haskell 中定义一个双函子。在这种情况下，所有三个范畴都是相同的：Haskell 类型的范畴。双函子是一种带有两个类型参数的类型构造函数。Bifunctor这是直接从库中获取的类型类的定义Control.Bifunctor：

Let’s define a bifunctor in Haskell. In this case all three categories are the same: the category of Haskell types. A bifunctor is a type constructor that takes two type arguments. Here’s the definition of the Bifunctor typeclass taken directly from the library Control.Bifunctor:

class Bifunctor f where
    bimap :: (a -> c) -> (b -> d) -> f a b -> f c d
    bimap g h = first g . second h
    first :: (a -> c) -> f a b -> f c b
    first g = bimap g id
    second :: (b -> d) -> f a b -> f a d
    second = bimap id

class Bifunctor f where
    bimap :: (a -> c) -> (b -> d) -> f a b -> f c d
    bimap g h = first g . second h
    first :: (a -> c) -> f a b -> f c b
    first g = bimap g id
    second :: (b -> d) -> f a b -> f a d
    second = bimap id

类型变量f表示双函子。您可以看到，在所有类型签名中，它始终应用于两个类型参数。第一个类型签名定义bimap：同时两个函数的映射。结果是一个提升函数 ，(f a b -> f c d)对 bifunctor 的类型构造函数生成的类型进行操作。在和bimap方面有一个默认实现，这表明每个参数中单独具有函子性就足以定义双函子。firstsecond

The type variable f represents the bifunctor. You can see that in all type signatures it’s always applied to two type arguments. The first type signature defines bimap: a mapping of two functions at once. The result is a lifted function, (f a b -> f c d), operating on types generated by the bifunctor’s type constructor. There is a default implementation of bimap in terms of first and second, which shows that it’s enough to have functoriality in each argument separately to be able to define a bifunctor.

双图

bimap

另外两个类型签名first和是分别见证第一个和第二个参数中的函数性的second两个s。fmapf

The two other type signatures, first and second, are the two fmaps witnessing the functoriality of f in the first and the second argument, respectively.

类型类定义为它们提供了默认实现bimap。

The typeclass definition provides default implementations for both of them in terms of bimap.

声明 的实例时Bifunctor，您可以选择实现并接受和bimap的默认值，或者同时实现和并接受默认值（当然，您可以实现所有三个，但随后由您来确保它们以这种方式相互关联）。firstsecondfirstsecondbimap

When declaring an instance of Bifunctor, you have a choice of either implementing bimap and accepting the defaults for first and second, or implementing both first and second and accepting the default for bimap (of course, you may implement all three of them, but then it’s up to you to make sure they are related to each other in this manner).

9.2乘积和余积双函子

9.2 Product and Coproduct Bifunctors

双函子的一个重要例子是分类乘积——由通用构造定义的两个对象的乘积。如果任何一对对象都存在乘积，则从这些对象到乘积的映射是双函数的。这在一般情况下是正确的，在 Haskell 中尤其如此。这是Bifunctor配对构造函数的实例 - 最简单的产品类型：

An important example of a bifunctor is the categorical product — a product of two objects that is defined by a universal construction. If the product exists for any pair of objects, the mapping from those objects to the product is bifunctorial. This is true in general, and in Haskell in particular. Here’s the Bifunctor instance for a pair constructor — the simplest product type:

instance Bifunctor (,) where
    bimap f g (x, y) = (f x, g y)

instance Bifunctor (,) where
    bimap f g (x, y) = (f x, g y)

没有太多选择：bimap只需将第一个函数应用于第一个组件，将第二个函数应用于一对中的第二个组件。考虑到类型，代码几乎是自己编写的：

There isn’t much choice: bimap simply applies the first function to the first component, and the second function to the second component of a pair. The code pretty much writes itself, given the types:

bimap :: (a -> c) -> (b -> d) -> (a, b) -> (c, d)

bimap :: (a -> c) -> (b -> d) -> (a, b) -> (c, d)

这里双函子的作用是生成类型对，例如：

The action of the bifunctor here is to make pairs of types, for instance:

(,) a b = (a, b)

(,) a b = (a, b)

根据对偶性，如果一个余积是为一个范畴中的每对对象定义的，那么它也是一个双函子。在 Haskell 中，这是通过Either类型构造函数作为 的实例来举例说明的Bifunctor：

By duality, a coproduct, if it’s defined for every pair of objects in a category, is also a bifunctor. In Haskell, this is exemplified by the Either type constructor being an instance of Bifunctor:

instance Bifunctor Either where
    bimap f _ (Left x)  = Left (f x)
    bimap _ g (Right y) = Right (g y)

instance Bifunctor Either where
    bimap f _ (Left x)  = Left (f x)
    bimap _ g (Right y) = Right (g y)

这段代码也是自己写的。

This code also writes itself.

现在，还记得我们讨论过幺半群范畴吗？幺半群范畴定义了作用于对象的二元运算符以及单位对象。我提到过这Set是一个关于笛卡尔积的幺半群范畴，以单例为一个单位。它也是一个关于不相交并的幺半群范畴，以空集为单位。我没有提到的是，幺半群范畴的要求之一是二元运算符是双函子。这是一个非常重要的要求——我们希望幺半群积与由态射定义的范畴结构兼容。我们现在距离幺半群范畴的完整定义又近了一步（在我们到达那里之前，我们仍然需要了解自然性）。

Now, remember when we talked about monoidal categories? A monoidal category defines a binary operator acting on objects, together with a unit object. I mentioned that Set is a monoidal category with respect to cartesian product, with the singleton set as a unit. And it’s also a monoidal category with respect to disjoint union, with the empty set as a unit. What I haven’t mentioned is that one of the requirements for a monoidal category is that the binary operator be a bifunctor. This is a very important requirement — we want the monoidal product to be compatible with the structure of the category, which is defined by morphisms. We are now one step closer to the full definition of a monoidal category (we still need to learn about naturality, before we can get there).

9.3函数代数数据类型

9.3 Functorial Algebraic Data Types

我们已经看到了几个参数化数据类型的示例，这些数据类型最终都是函子——我们能够fmap为它们定义。复杂的数据类型是由简单的数据类型构造而成的。特别是，代数数据类型 (ADT) 是使用和与积创建的。我们刚刚看到和和乘积是函数式的。我们还知道函子可以组合。因此，如果我们能够证明 ADT 的基本构建块是函数式的，那么我们就会知道参数化 ADT 也是函数式的。

We’ve seen several examples of parameterized data types that turned out to be functors — we were able to define fmap for them. Complex data types are constructed from simpler data types. In particular, algebraic data types (ADTs) are created using sums and products. We have just seen that sums and products are functorial. We also know that functors compose. So if we can show that the basic building blocks of ADTs are functorial, we’ll know that parameterized ADTs are functorial too.

那么参数化代数数据类型的构建块是什么？首先，有些项不依赖于函子的类型参数，例如NothinginMaybe或Nilin List。它们相当于Const函子。请记住，Const函子忽略其类型参数（实际上，第二个类型参数，这是我们感兴趣的类型参数，第一个类型参数保持不变）。

So what are the building blocks of parameterized algebraic data types? First, there are the items that have no dependency on the type parameter of the functor, like Nothing in Maybe, or Nil in List. They are equivalent to the Const functor. Remember, the Const functor ignores its type parameter (really, the second type parameter, which is the one of interest to us, the first one being kept constant).

然后是简单封装类型参数本身的元素，Just例如Maybe. 它们相当于恒等函子。我之前提到过恒等函子，作为Cat中的恒等态射，但没有给出它在 Haskell 中的定义。这里是：

Then there are the elements that simply encapsulate the type parameter itself, like Just in Maybe. They are equivalent to the identity functor. I mentioned the identity functor previously, as the identity morphism in Cat, but didn’t give its definition in Haskell. Here it is:

data Identity a = Identity a

data Identity a = Identity a

instance Functor Identity where
    fmap f (Identity x) = Identity (f x)

instance Functor Identity where
    fmap f (Identity x) = Identity (f x)

您可以将其视为Identity最简单的容器，它始终仅存储一个（不可变）类型的值a。

You can think of Identity as the simplest possible container that always stores just one (immutable) value of type a.

代数数据结构中的其他所有内容都是使用积和和从这两个原语构造的。

Everything else in algebraic data structures is constructed from these two primitives using products and sums.

有了这些新知识，让我们重新审视一下Maybe类型构造函数：

With this new knowledge, let’s have a fresh look at the Maybe type constructor:

data Maybe a = Nothing | Just a

data Maybe a = Nothing | Just a

它是两种类型的和，我们现在知道这个和是函子的。第一部分，Nothing可以表示为Const ()作用于a（ 的第一个类型参数Const设置为单位 - 稍后我们将看到 的更有趣的用法Const）。第二部分只是恒等函子的不同名称。我们可以将Maybe，直到同构定义为：

It’s a sum of two types, and we now know that the sum is functorial. The first part, Nothing can be represented as a Const () acting on a (the first type parameter of Const is set to unit — later we’ll see more interesting uses of Const). The second part is just a different name for the identity functor. We could have defined Maybe, up to isomorphism, as:

type Maybe a = Either (Const () a) (Identity a)

type Maybe a = Either (Const () a) (Identity a)

具有两个函子和的双Maybe函子的组成也是如此。（实际上是一个双函子，但在这里我们总是部分应用它。）EitherConst ()IdentityConst

So Maybe is the composition of the bifunctor Either with two functors, Const () and Identity. (Const is really a bifunctor, but here we always use it partially applied.)

我们已经知道，函子的组合就是一个函子——我们可以很容易地说服自己，双函子也是如此。我们所需要的只是弄清楚双函子与两个函子的组合如何作用于态射。给定两个态射，我们只需用一个函子提升一个态射，用另一个函子提升另一个态射。然后，我们用双函子提升所得到的一对提升的态射。

We’ve already seen that a composition of functors is a functor — we can easily convince ourselves that the same is true of bifunctors. All we need is to figure out how a composition of a bifunctor with two functors works on morphisms. Given two morphisms, we simply lift one with one functor and the other with the other functor. We then lift the resulting pair of lifted morphisms with the bifunctor.

我们可以用 Haskell 来表达这个组合。让我们定义一个由双函子参数化的数据类型bf（它是一个类型变量，是接受两种类型作为参数的类型构造函数）、两个函子fu和gu（每个函子接受一个类型变量的类型构造函数）以及两个常规类型a和b。我们应用fu到a和guto b，然后应用bf到结果的两种类型：

We can express this composition in Haskell. Let’s define a data type that is parameterized by a bifunctor bf (it’s a type variable that is a type constructor that takes two types as arguments), two functors fu and gu (type constructors that take one type variable each), and two regular types a and b. We apply fu to a and gu to b, and then apply bf to the resulting two types:

newtype BiComp bf fu gu a b = BiComp (bf (fu a) (gu b))

newtype BiComp bf fu gu a b = BiComp (bf (fu a) (gu b))

这就是对象或类型的组合。请注意，在 Haskell 中，我们如何将类型构造函数应用于类型，就像我们将函数应用于参数一样。语法是一样的。

That’s the composition on objects, or types. Notice how in Haskell we apply type constructors to types, just like we apply functions to arguments. The syntax is the same.

如果您有点迷失，请尝试按此顺序BiComp申请Either、Const ()、Identity、a、 和。b您将恢复我们的基本版本Maybe b（a被忽略）。

If you’re getting a little lost, try applying BiComp to Either, Const (), Identity, a, and b, in this order. You will recover our bare-bone version of Maybe b (a is ignored).

新数据类型是andBiComp中的双函子，但前提是is 本身是 a且且是s。编译器必须知道将有available for的定义以及for和的定义。在 Haskell 中，这在实例声明中表示为前提条件：一组类约束，后跟一个双箭头：abbfBifunctorfuguFunctorbimapbffmapfugu

The new data type BiComp is a bifunctor in a and b, but only if bf is itself a Bifunctor and fu and gu are Functors. The compiler must know that there will be a definition of bimap available for bf, and definitions of fmap for fu and gu. In Haskell, this is expressed as a precondition in the instance declaration: a set of class constraints followed by a double arrow:

instance (Bifunctor bf, Functor fu, Functor gu) =>
  Bifunctor (BiComp bf fu gu) where
    bimap f1 f2 (BiComp x) = BiComp ((bimap (fmap f1) (fmap f2)) x)

instance (Bifunctor bf, Functor fu, Functor gu) =>
  Bifunctor (BiComp bf fu gu) where
    bimap f1 f2 (BiComp x) = BiComp ((bimap (fmap f1) (fmap f2)) x)

bimapfor的实现BiComp以bimapforbf和两个fmapforfu和 的形式给出gu。每当使用时，编译器都会自动推断所有类型并选择正确的重载函数BiComp。

The implementation of bimap for BiComp is given in terms of bimap for bf and the two fmaps for fu and gu. The compiler automatically infers all the types and picks the correct overloaded functions whenever BiComp is used.

的x定义中的bimap具有类型：

The x in the definition of bimap has the type:

bf (fu a) (gu b)

bf (fu a) (gu b)

这是相当拗口的。外层bimap突破外层bf，两人分别fmap往下挖fu和gu。f1如果和的类型f2是：

which is quite a mouthful. The outer bimap breaks through the outer bf layer, and the two fmaps dig under fu and gu, respectively. If the types of f1 and f2 are:

f1 :: a -> a'
f2 :: b -> b'

f1 :: a -> a'
f2 :: b -> b'

那么最终结果的类型为bf (fu a') (gu b')：

then the final result is of the type bf (fu a') (gu b'):

bimap (fu a -> fu a') -> (gu b -> gu b') 
  -> bf (fu a) (gu b) -> bf (fu a') (gu b')

bimap (fu a -> fu a') -> (gu b -> gu b') 
  -> bf (fu a) (gu b) -> bf (fu a') (gu b')

如果您喜欢拼图游戏，这些类型的操作可以为您带来数小时的娱乐。

If you like jigsaw puzzles, these kinds of type manipulations can provide hours of entertainment.

所以事实证明，我们不必证明这Maybe是一个函子——这一事实是根据它被构造为两个函子原语之和的方式得出的。

So it turns out that we didn’t have to prove that Maybe was a functor — this fact followed from the way it was constructed as a sum of two functorial primitives.

敏锐的读者可能会问：如果Functor代数数据类型实例的推导如此机械，难道不能由编译器自动执行吗？确实，它可以，而且确实如此。您需要通过在源文件顶部包含以下行来启用特定的 Haskell 扩展：

A perceptive reader might ask the question: If the derivation of the Functor instance for algebraic data types is so mechanical, can’t it be automated and performed by the compiler? Indeed, it can, and it is. You need to enable a particular Haskell extension by including this line at the top of your source file:

{-# LANGUAGE DeriveFunctor #-}

{-# LANGUAGE DeriveFunctor #-}

然后添加deriving Functor到您的数据结构：

and then add deriving Functor to your data structure:

data Maybe a = Nothing | Just a
  deriving Functor

data Maybe a = Nothing | Just a
  deriving Functor

fmap并将为您实施相应的操作。

and the corresponding fmap will be implemented for you.

代数数据结构的规律性使得不仅可以派生出Functor几个其他类型类的实例，包括Eq我之前提到的类型类。还可以选择教编译器派生您自己的类型类的实例，但这更高级一些。但其想法是相同的：您提供基本构建块以及求和和乘积的行为，然后让编译器计算其余部分。

The regularity of algebraic data structures makes it possible to derive instances not only of Functor but of several other type classes, including the Eq type class I mentioned before. There is also the option of teaching the compiler to derive instances of your own typeclasses, but that’s a bit more advanced. The idea though is the same: You provide the behavior for the basic building blocks and sums and products, and let the compiler figure out the rest.

9.4 C++中的函子

9.4 Functors in C++

如果您是一名 C++ 程序员，那么就实现函子而言，您显然需要靠自己。但是，您应该能够识别 C++ 中某些类型的代数数据结构。如果将这样的数据结构做成通用模板，你应该能够快速实现fmap它。

If you are a C++ programmer, you obviously are on your own as far as implementing functors goes. However, you should be able to recognize some types of algebraic data structures in C++. If such a data structure is made into a generic template, you should be able to quickly implement fmap for it.

让我们看一下树数据结构，我们在 Haskell 中将其定义为递归求和类型：

Let’s have a look at a tree data structure, which we would define in Haskell as a recursive sum type:

data Tree a = Leaf a | Node (Tree a) (Tree a)
    deriving Functor

data Tree a = Leaf a | Node (Tree a) (Tree a)
    deriving Functor

正如我之前提到的，在 C++ 中实现求和类型的一种方法是通过类层次结构。在面向对象的语言中，将其实现fmap为基类的虚函数Functor，然后在所有子类中重写它是很自然的。不幸的是，这是不可能的，因为它fmap是一个模板，不仅通过它所作用的对象的类型（指针this）来参数化，而且还通过应用于它的函数的返回类型来参数化。虚函数无法在 C++ 中模板化。我们将实现fmap为通用自由函数，并将模式匹配替换为dynamic_cast.

As I mentioned before, one way of implementing sum types in C++ is through class hierarchies. It would be natural, in an object-oriented language, to implement fmap as a virtual function of the base class Functor and then override it in all subclasses. Unfortunately this is impossible because fmap is a template, parameterized not only by the type of the object it’s acting upon (the this pointer) but also by the return type of the function that’s been applied to it. Virtual functions cannot be templatized in C++. We’ll implement fmap as a generic free function, and we’ll replace pattern matching with dynamic_cast.

基类必须定义至少一个虚函数才能支持动态转换，因此我们将析构函数设为虚函数（在任何情况下这都是一个好主意）：

The base class must define at least one virtual function in order to support dynamic casting, so we’ll make the destructor virtual (which is a good idea in any case):

template<class T>
struct Tree {
    virtual ~Tree() {};
};

template<class T>
struct Tree {
    virtual ~Tree() {};
};

这Leaf只是一个Identity伪装的函子：

The Leaf is just an Identity functor in disguise:

template<class T>
struct Leaf : public Tree<T> {
    T _label;
    Leaf(T l) : _label(l) {}
};

template<class T>
struct Leaf : public Tree<T> {
    T _label;
    Leaf(T l) : _label(l) {}
};

这Node是一个产品类型：

The Node is a product type:

template<class T>
struct Node : public Tree<T> {
    Tree<T> * _left;
    Tree<T> * _right;
    Node(Tree<T> * l, Tree<T> * r) : _left(l), _right(r) {}
};

template<class T>
struct Node : public Tree<T> {
    Tree<T> * _left;
    Tree<T> * _right;
    Node(Tree<T> * l, Tree<T> * r) : _left(l), _right(r) {}
};

在实现时，fmap我们利用Tree. 该Leaf案例应用Identity的版本fmap，并且该Node案例被视为由Tree函子的两个副本组成的双函子。作为一名 C++ 程序员，您可能不习惯用这些术语分析代码，但这是分类思维的一个很好的练习。

When implementing fmap we take advantage of dynamic dispatching on the type of the Tree. The Leaf case applies the Identity version of fmap, and the Node case is treated like a bifunctor composed with two copies of the Tree functor. As a C++ programmer, you’re probably not used to analyzing code in these terms, but it’s a good exercise in categorical thinking.

template<class A, class B>
Tree<B> * fmap(std::function<B(A)> f, Tree<A> * t)
{
    Leaf<A> * pl = dynamic_cast <Leaf<A>*>(t);
    if (pl)
        return new Leaf<B>(f (pl->_label));
    Node<A> * pn = dynamic_cast<Node<A>*>(t);
    if (pn)
        return new Node<B>( fmap<A>(f, pn->_left)
                          , fmap<A>(f, pn->_right));
    return nullptr;
}

template<class A, class B>
Tree<B> * fmap(std::function<B(A)> f, Tree<A> * t)
{
    Leaf<A> * pl = dynamic_cast <Leaf<A>*>(t);
    if (pl)
        return new Leaf<B>(f (pl->_label));
    Node<A> * pn = dynamic_cast<Node<A>*>(t);
    if (pn)
        return new Node<B>( fmap<A>(f, pn->_left)
                          , fmap<A>(f, pn->_right));
    return nullptr;
}

为简单起见，我决定忽略内存和资源管理问题，但在生产代码中，您可能会使用智能指针（唯一或共享，具体取决于您的策略）。

For simplicity, I decided to ignore memory and resource management issues, but in production code you would probably use smart pointers (unique or shared, depending on your policy).

将其与 Haskell 实现进行比较fmap：

Compare it with the Haskell implementation of fmap:

instance Functor Tree where
    fmap f (Leaf a) = Leaf (f a)
    fmap f (Node t t') = Node (fmap f t) (fmap f t')

instance Functor Tree where
    fmap f (Leaf a) = Leaf (f a)
    fmap f (Node t t') = Node (fmap f t) (fmap f t')

该实现也可以由编译器自动导出。

This implementation can also be automatically derived by the compiler.

9.5 Writer函子

9.5 The Writer Functor

我承诺我会回到我之前描述的克莱斯利范畴。该范畴中的态射被表示为返回Writer数据结构的“修饰”函数。

I promised that I would come back to the Kleisli category I described earlier. Morphisms in that category were represented as “embellished” functions returning the Writer data structure.

type Writer a = (a, String)

type Writer a = (a, String)

我说过修饰与内函子有某种关系。事实上，Writer类型构造函数在a. 我们甚至不需要实现fmap它，因为它只是一个简单的产品类型。

I said that the embellishment was somehow related to endofunctors. And, indeed, the Writer type constructor is functorial in a. We don’t even have to implement fmap for it, because it’s just a simple product type.

但一般来说，克莱斯利范畴和函子之间的关系是什么？克莱斯利范畴作为一个范畴，定义了组成和同一性。让我提醒您一下，成分是由鱼类操作员给出的：

But what’s the relation between a Kleisli category and a functor — in general? A Kleisli category, being a category, defines composition and identity. Let’ me remind you that the composition is given by the fish operator:

(>=>) :: (a -> Writer b) -> (b -> Writer c) -> (a -> Writer c)
m1 >=> m2 = \x -> 
    let (y, s1) = m1 x
        (z, s2) = m2 y
    in (z, s1 ++ s2)

(>=>) :: (a -> Writer b) -> (b -> Writer c) -> (a -> Writer c)
m1 >=> m2 = \x -> 
    let (y, s1) = m1 x
        (z, s2) = m2 y
    in (z, s1 ++ s2)

以及由称为 的函数进行的恒等态射return：

and the identity morphism by a function called return:

return :: a -> Writer a
return x = (x, "")

return :: a -> Writer a
return x = (x, "")

事实证明，如果您足够长地查看这两个函数的类型（我的意思是，足够长），您可以找到一种方法将它们组合起来以生成具有正确类型签名的函数来充当fmap. 像这样：

It turns out that, if you look at the types of these two functions long enough (and I mean, long enough), you can find a way to combine them to produce a function with the right type signature to serve as fmap. Like this:

fmap f = id >=> (\x -> return (f x))

fmap f = id >=> (\x -> return (f x))

在这里，fish 运算符组合了两个函数：其中一个是熟悉的id，另一个是 lambda，它应用于对 lambda 参数return进行操作的结果。f最难的部分可能是使用id. Fish 运算符的参数不应该是一个采用“正常”类型并返回修饰类型的函数吗？嗯，不是真的。a没有人说它a -> Writer b一定是“正常”类型。它是一个类型变量，因此它可以是任何东西，特别是它可以是修饰类型，例如Writer b.

Here, the fish operator combines two functions: one of them is the familiar id, and the other is a lambda that applies return to the result of acting with f on the lambda’s argument. The hardest part to wrap your brain around is probably the use of id. Isn’t the argument to the fish operator supposed to be a function that takes a “normal” type and returns an embellished type? Well, not really. Nobody says that a in a -> Writer b must be a “normal” type. It’s a type variable, so it can be anything, in particular it can be an embellished type, like Writer b.

因此id将把Writer a它变成Writer a. Fish 操作符将找出 的值a并将其传递x给 lambda。在那里，f将把它变成 ab并return修饰它，使其成为Writer b。把它们放在一起，我们最终得到一个接受Writer a并返回 的函数Writer b，这正是fmap应该产生的结果。

So id will take Writer a and turn it into Writer a. The fish operator will fish out the value of a and pass it as x to the lambda. There, f will turn it into a b and return will embellish it, making it Writer b. Putting it all together, we end up with a function that takes Writer a and returns Writer b, exactly what fmap is supposed to produce.

请注意，这个参数非常通用：您可以替换Writer为任何类型构造函数。只要它支持 Fish 操作符 和，您也return可以定义。fmap所以 Kleisli 范畴中的修饰始终是函子。（不过，并不是每个函子都会产生克莱斯利范畴。）

Notice that this argument is very general: you can replace Writer with any type constructor. As long as it supports a fish operator and return, you can define fmap as well. So the embellishment in the Kleisli category is always a functor. (Not every functor, though, gives rise to a Kleisli category.)

您可能想知道fmap我们刚刚定义的 是否与fmap编译器为我们派生的相同deriving Functor。有趣的是，确实如此。这是由于 Haskell 实现多态函数的方式造成的。它被称为参数多态性，并且它是所谓的免费定理的来源。fmap这些定理之一说，如果给定类型构造函数有一个保留身份的实现，那么它必须是唯一的。

You might wonder if the fmap we have just defined is the same fmap the compiler would have derived for us with deriving Functor. Interestingly enough, it is. This is due to the way Haskell implements polymorphic functions. It’s called parametric polymorphism, and it’s a source of so called theorems for free. One of those theorems says that, if there is an implementation of fmap for a given type constructor, one that preserves identity, then it must be unique.

9.6协变和逆变函子

9.6 Covariant and Contravariant Functors

现在我们已经回顾了 writer 函子，让我们回到 reader 函子。它基于部分应用的函数箭头类型构造函数：

Now that we’ve reviewed the writer functor, let’s go back to the reader functor. It was based on the partially applied function-arrow type constructor:

(->) r

(->) r

我们可以将其重写为类型同义词：

We can rewrite it as a type synonym:

type Reader r a = r -> a

type Reader r a = r -> a

Functor正如我们之前看到的，该实例如下：

for which the Functor instance, as we’ve seen before, reads:

instance Functor (Reader r) where
    fmap f g = f . g

instance Functor (Reader r) where
    fmap f g = f . g

但就像pair类型构造函数或Either类型构造函数一样，函数类型构造函数也接受两个类型参数。这对 和Either在两个论证中都是函子——它们是双函子。函数构造函数也是双函子吗？

But just like the pair type constructor, or the Either type constructor, the function type constructor takes two type arguments. The pair and Either were functorial in both arguments — they were bifunctors. Is the function constructor a bifunctor too?

让我们尝试在第一个参数中使其成为函数式的。我们将从类型同义词开始——它就像Reader但参数翻转了：

Let’s try to make it functorial in the first argument. We’ll start with a type synonym — it’s just like the Reader but with the arguments flipped:

type Op r a = a -> r

type Op r a = a -> r

这次我们修复了返回类型 ，r并改变了参数类型a。让我们看看是否可以以某种方式匹配类型来实现fmap，它将具有以下类型签名：

This time we fix the return type, r, and vary the argument type, a. Let’s see if we can somehow match the types in order to implement fmap, which would have the following type signature:

fmap :: (a -> b) -> (a -> r) -> (b -> r)

fmap :: (a -> b) -> (a -> r) -> (b -> r)

只有两个函数a分别接受和返回b和r，根本没有办法构建一个函数接受b和返回r！如果我们能以某种方式反转第一个函数，使其接受b并返回，情况就会有所不同a。我们不能反转任意函数，但我们可以转到相反的范畴。

With just two functions taking a and returning, respectively, b and r, there is simply no way to build a function taking b and returning r! It would be different if we could somehow invert the first function, so that it took b and returned a instead. We can’t invert an arbitrary function, but we can go to the opposite category.

简短回顾：对于每个范畴C都有一个双重范畴C ^op。它是一个与C具有相同对象的范畴，但所有箭头都相反。

A short recap: For every category C there is a dual category C^op. It’s a category with the same objects as C, but with all the arrows reversed.

考虑一个介于C ^op和其他范畴D之间的函子：

F :: C ^op → D

这样的函子将C ^op中的态射f ^op :: a → b映射到态射F f ^op :: F a → F b在D . 但态射f ^op秘密地对应于原始范畴C中的某个态射f :: b → a。注意反转。

Consider a functor that goes between C^op and some other category D:

F :: C^op → D

Such a functor maps a morphism f^op :: a → b in C^op to the morphism F f^op :: F a → F b in D. But the morphism f^op secretly corresponds to some morphism f :: b → a in the original category C. Notice the inversion.

现在，F是一个常规函子，但我们可以基于F定义另一个映射，它不是函子 - 我们称之为G。这是从C到D的映射。它以与F相同的方式映射对象，但当涉及到映射态射时，它会反转它们。它采用C中的态射f :: b → a，首先将其映射到相反的态射f ^op :: a → b，然后在其上使用函子 F ，以获得F f ^op :: F a → F b。

Now, F is a regular functor, but there is another mapping we can define based on F, which is not a functor — let’s call it G. It’s a mapping from C to D. It maps objects the same way F does, but when it comes to mapping morphisms, it reverses them. It takes a morphism f :: b → a in C, maps it first to the opposite morphism f^op :: a → b and then uses the functor F on it, to get F f^op :: F a → F b.

考虑到F a与 Ga相同，F b与G b相同，整个过程可以描述为：

G f :: (b → a) → (G a → G b)

这是一个“函子一个转折。” 以这种方式反转态射方向的范畴映射称为逆变函子。请注意，逆变函子只是来自相反范畴的常规函子。顺便说一句，常规函子（我们迄今为止一直在研究的那种）称为协变函子。

Considering that F a is the same as G a and F b is the same as G b, the whole trip can be described as:

G f :: (b → a) → (G a → G b)

It’s a “functor with a twist.” A mapping of categories that inverts the direction of morphisms in this manner is called a contravariant functor. Notice that a contravariant functor is just a regular functor from the opposite category. The regular functors, by the way — the kind we’ve been studying thus far — are called covariant functors.

这是在 Haskell 中定义逆变函子（实际上是逆变内函子）的类型类：

Here’s the typeclass defining a contravariant functor (really, a contravariant endofunctor) in Haskell:

class Contravariant f where
    contramap :: (b -> a) -> (f a -> f b)

class Contravariant f where
    contramap :: (b -> a) -> (f a -> f b)

我们的类型构造函数Op是它的一个实例：

Our type constructor Op is an instance of it:

instance Contravariant (Op r) where
    -- (b -> a) -> Op r a -> Op r b
    contramap f g = g . f

instance Contravariant (Op r) where
    -- (b -> a) -> Op r a -> Op r b
    contramap f g = g . f

请注意，该函数f将自身插入到— 函数的内容之前（即右侧）。Opg

Notice that the function f inserts itself before (that is, to the right of) the contents of Op — the function g.

如果您注意到 for 只是参数翻转的函数组合运算符，那么 for 的定义可能会更加contramap简洁。Op有一个用于翻转参数的特殊函数，称为flip：

The definition of contramap for Op may be made even terser, if you notice that it’s just the function composition operator with the arguments flipped. There is a special function for flipping arguments, called flip:

flip :: (a -> b -> c) -> (b -> a -> c)
  flip f y x = f x y

flip :: (a -> b -> c) -> (b -> a -> c)
  flip f y x = f x y

有了它，我们得到：

With it, we get:

contramap = flip (.)

contramap = flip (.)

9.7函子

9.7 Profunctors

我们已经看到，函数箭头运算符的第一个参数是逆变的，第二个参数是协变的。这样的野兽有名字吗？事实证明，如果目标范畴是Set，那么这样的野兽就被称为profunctor。因为逆变函子等价于相反范畴的协变函子，所以泛函子定义为：

C ^op × D → Set

We’ve seen that the function-arrow operator is contravariant in its first argument and covariant in the second. Is there a name for such a beast? It turns out that, if the target category is Set, such a beast is called a profunctor. Because a contravariant functor is equivalent to a covariant functor from the opposite category, a profunctor is defined as:

C^op × D → Set

由于从第一个近似来看，Haskell 类型是集合，因此我们将名称应用于两个参数的Profunctor类型构造函数p，这在第一个参数中是反函子，在第二个参数中是函子。这是从库中获取的适当类型类Data.Profunctor：

Since, to first approximation, Haskell types are sets, we apply the name Profunctor to a type constructor p of two arguments, which is contra-functorial in the first argument and functorial in the second. Here’s the appropriate typeclass taken from the Data.Profunctor library:

class Profunctor p where
  dimap :: (a -> b) -> (c -> d) -> p b c -> p a d
  dimap f g = lmap f . rmap g
  lmap :: (a -> b) -> p b c -> p a c
  lmap f = dimap f id
  rmap :: (b -> c) -> p a b -> p a c
  rmap = dimap id

class Profunctor p where
  dimap :: (a -> b) -> (c -> d) -> p b c -> p a d
  dimap f g = lmap f . rmap g
  lmap :: (a -> b) -> p b c -> p a c
  lmap f = dimap f id
  rmap :: (b -> c) -> p a b -> p a c
  rmap = dimap id

所有三个函数都有默认实现。就像 with 一样Bifunctor，在声明 的实例时Profunctor，您可以选择实现并接受anddimap的默认值，或者同时实现and并接受默认值。lmaprmaplmaprmapdimap

All three functions come with default implementations. Just like with Bifunctor, when declaring an instance of Profunctor, you have a choice of either implementing dimap and accepting the defaults for lmap and rmap, or implementing both lmap and rmap and accepting the default for dimap.

迪马普

dimap

现在我们可以断言函数箭头运算符是 a 的实例Profunctor：

Now we can assert that the function-arrow operator is an instance of a Profunctor:

instance Profunctor (->) where
  dimap ab cd bc = cd . bc . ab
  lmap = flip (.)
  rmap = (.)

instance Profunctor (->) where
  dimap ab cd bc = cd . bc . ab
  lmap = flip (.)
  rmap = (.)

Profunctors 在 Haskell 透镜库中有其应用。当我们谈论结局和共结局时，我们会再次见到它们。

Profunctors have their application in the Haskell lens library. We’ll see them again when we talk about ends and coends.

9.8挑战

9.8 Challenges

1. 显示数据类型：

   data Pair a b = Pair a b

   是一个双函子。对于额外的信用，实施所有三种方法Bifunctor并使用等式推理来表明这些定义在可以应用时与默认实现兼容。

2. Show that the data type:

   data Pair a b = Pair a b

   is a bifunctor. For additional credit implement all three methods of Bifunctor and use equational reasoning to show that these definitions are compatible with the default implementations whenever they can be applied.

3. 显示 的标准定义Maybe和此脱糖之间的同构：

   type Maybe' a = Either (Const () a) (Identity a)

   提示：在两个实现之间定义两个映射。为了获得额外的分数，请使用等式推理证明它们是彼此相反的。

4. Show the isomorphism between the standard definition of Maybe and this desugaring:

   type Maybe' a = Either (Const () a) (Identity a)

   Hint: Define two mappings between the two implementations. For additional credit, show that they are the inverse of each other using equational reasoning.

5. 让我们尝试另一种数据结构。我称其为 aPreList因为它是 a 的先驱List。它用类型参数代替递归b。

   data PreList a b = Nil | Cons a b

   List您可以通过递归地应用于PreList自身来恢复我们之前对 a 的定义（当我们讨论不动点时，我们将看到它是如何完成的）。

   显示PreList是 的一个实例Bifunctor。

6. Let’s try another data structure. I call it a PreList because it’s a precursor to a List. It replaces recursion with a type parameter b.

   data PreList a b = Nil | Cons a b

   You could recover our earlier definition of a List by recursively applying PreList to itself (we’ll see how it’s done when we talk about fixed points).

   Show that PreList is an instance of Bifunctor.

7. 证明以下数据类型定义了a和中的双函子b：

   data K2 c a b = K2 c

   data Fst a b = Fst a

   data Snd a b = Snd b

   如需额外学分，请对照 Conor McBride 的论文《我左边的小丑，右边的小丑》检查您的解决方案。

8. Show that the following data types define bifunctors in a and b:

   data K2 c a b = K2 c

   data Fst a b = Fst a

   data Snd a b = Snd b

   For additional credit, check your solutions agains Conor McBride’s paper Clowns to the Left of me, Jokers to the Right.

9. 用 Haskell 以外的语言定义双函子。实现bimap该语言中的通用对。
10. Define a bifunctor in a language other than Haskell. Implement bimap for a generic pair in that language.
11. 应该std::map被视为两个模板参数Key和中的双函子或函子T吗？您将如何重新设计这种数据类型以实现这一目标？
12. Should std::map be considered a bifunctor or a profunctor in the two template arguments Key and T? How would you redesign this data type to make it so?

9.9致谢

9.9 Acknowledgment

与往常一样，非常感谢 Gershom Bazerman 审阅本文。

As usual, big thanks go to Gershom Bazerman for reviewing this article.

10.1通用结构

10.1 Universal Construction

让我们暂时忘记函数类型是集合，并尝试从头开始构造一个函数类型，或更一般地说，一个内部 hom 集。像往常一样，我们将从“集合”范畴中获取线索，但要小心避免使用集合的任何属性，以便该构造将自动适用于其他范畴。

Let’s forget for a moment that function types are sets and try to construct a function type, or more generally, an internal hom-set, from scratch. As usual, we’ll take our cues from the Set category, but carefully avoid using any properties of sets, so that the construction will automatically work for other categories.

由于函数类型与参数类型和结果类型的关系，因此可以将其视为复合类型。我们已经了解了复合类型的构造——那些涉及对象之间关系的构造。我们使用通用结构来定义产品类型和联产品类型。我们可以使用相同的技巧来定义函数类型。我们需要一个涉及三个对象的模式：我们正在构造的函数类型、参数类型和结果类型。

A function type may be considered a composite type because of its relationship to the argument type and the result type. We’ve already seen the constructions of composite types — those that involved relationships between objects. We used universal constructions to define a product type and a coproduct types. We can use the same trick to define a function type. We will need a pattern that involves three objects: the function type that we are constructing, the argument type, and the result type.

连接这三种类型的明显模式称为函数应用或求值。给定一个函数类型的候选者，让我们调用它z（注意，如果我们不在范畴Set中，这只是一个像任何其他对象一样的对象），以及参数类型a（一个对象），应用程序将此对映射到结果类型b（对象）。我们有三个对象，其中两个是固定的（代表参数类型和结果类型的）。

The obvious pattern that connects these three types is called function application or evaluation. Given a candidate for a function type, let’s call it z (notice that, if we are not in the category Set, this is just an object like any other object), and the argument type a (an object), the application maps this pair to the result type b (an object). We have three objects, two of them fixed (the ones representing the argument type and the result type).

我们还有应用程序，它是一个映射。我们如何将这种映射合并到我们的模式中？如果我们被允许查看对象内部，我们可以将一个函数f（ 的一个元素z）与一个参数x（ 的一个元素a）配对，并将其映射到（ tof x的应用程序，它是 的一个元素）。fxb

We also have the application, which is a mapping. How do we incorporate this mapping into our pattern? If we were allowed to look inside objects, we could pair a function f (an element of z) with an argument x (an element of a) and map it to f x (the application of f to x, which is an element of b).

在 Set 中，我们可以从一组函数 z 中选择一个函数 f，并且可以从集合（类型）a 中选择一个参数 x。我们得到集合（类型）b 中的一个元素 fx。

In Set we can pick a function f from a set of functions z and we can pick an argument x from the set (type) a. We get an element f x in the set (type) b.

但我们不只处理单个对(f, x)，还可以讨论函数类型和参数类型的整个乘积。产品是一个对象，我们可以选择从该对象到 的箭头作为我们的应用程序态射。在Set中，是将每对映射到的函数。zaz×agbg(f, x)f x

But instead of dealing with individual pairs (f, x), we can as well talk about the whole product of the function type z and the argument type a. The product z×a is an object, and we can pick, as our application morphism, an arrow g from that object to b. In Set, g would be the function that maps every pair (f, x) to f x.

这就是模式：两个对象的乘积z并通过态射a连接到另一个对象。bg

So that’s the pattern: a product of two objects z and a connected to another object b by a morphism g.

对象和态射的模式，是通用构造的起点

A pattern of objects and morphisms that is the starting point of the universal construction

该模式是否足够具体，可以使用通用结构来挑选出函数类型？并非在每个范畴中。但在我们感兴趣的范畴中确实如此。还有一个问题：是否可以在不先定义产品的情况下定义函数对象？有些范畴中没有产品，或者没有适用于所有对象对的产品。答案是否定的：如果没有产品类型，就没有功能类型。稍后当我们讨论指数时我们会再讨论这一点。

Is this pattern specific enough to single out the function type using a universal construction? Not in every category. But in the categories of interest to us it is. And another question: Would it be possible to define a function object without first defining a product? There are categories in which there is no product, or there isn’t a product for all pairs of objects. The answer is no: there is no function type, if there is no product type. We’ll come back to this later when we talk about exponentials.

让我们回顾一下通用构造。我们从对象和态射的模式开始。这是我们不精确的查询，它通常会产生大量的命中。特别是，在Set中，几乎所有事物都相互关联。我们可以采用任何对象z，形成其与 的乘积a，并且将有一个从它 到 的函数b（除非b是空集）。

Let’s review the universal construction. We start with a pattern of objects and morphisms. That’s our imprecise query, and it usually yields lots and lots of hits. In particular, in Set, pretty much everything is connected to everything. We can take any object z, form its product with a, and there’s going to be a function from it to b (except when b is an empty set).

这就是我们应用秘密武器的时候：排名。这通常是通过要求候选对象之间存在唯一的映射来完成的——这种映射以某种方式分解了我们的构造。在我们的例子中，我们将判定，当且仅当存在从到的唯一z映射，使得通过应用 来应用因子时，与到的态射一起优于具有其自身应用的其他态射。（提示：边看图边读这句话。）gz×abz'g'hz'zg'g

That’s when we apply our secret weapon: ranking. This is usually done by requiring that there be a unique mapping between candidate objects — a mapping that somehow factorizes our construction. In our case, we’ll decree that z together with the morphism g from z×a to b is better than some other z' with its own application g', if and only if there is a unique mapping h from z' to z such that the application of g' factors through the application of g. (Hint: Read this sentence while looking at the picture.)

在函数对象的候选者之间建立排名

Establishing a ranking between candidates for the function object

现在这是棘手的部分，也是我推迟这个特殊的通用构造至今的主要原因。给定态射，我们想要闭合同时具有和 与交叉的h :: z'-> z图。考虑到从到 的映射，我们真正需要的是从到 的映射。现在，在讨论了产品的功能性之后，我们知道了如何去做。因为乘积本身是一个函子（更准确地说是一个内双函子），所以可以提升态射对。换句话说，我们不仅可以定义对象的乘积，还可以定义态射的乘积。z'zahz'zz'×az×a

Now here’s the tricky part, and the main reason I postponed this particular universal construction till now. Given the morphism h :: z'-> z, we want to close the diagram that has both z' and z crossed with a. What we really need, given the mapping h from z' to z, is a mapping from z'×a to z×a. And now, after discussing the functoriality of the product, we know how to do it. Because the product itself is a functor (more precisely an endo-bi-functor), it’s possible to lift pairs of morphisms. In other words, we can define not only products of objects but also products of morphisms.

由于我们没有触及乘积的第二个组成部分z'×a，因此我们将提升一对态射(h, id)，其中id是 上的恒等式a。

Since we are not touching the second component of the product z'×a, we will lift the pair of morphisms (h, id), where id is an identity on a.

因此，我们可以通过以下方式将一个应用程序g从另一个应用程序中分解出来g'：

So, here’s how we can factor one application, g, out of another application g':

g' = g ∘ (h × id)

g' = g ∘ (h × id)

这里的关键是乘积对态射的作用。

The key here is the action of the product on morphisms.

普遍构造的第三部分是选择普遍最好的对象。让我们调用这个对象a⇒b（将其视为一个对象的符号名称，不要与 Haskell 类型类约束混淆 - 我稍后将讨论命名它的不同方式）。这个对象有它自己的应用程序——从(a⇒b)×ato 的态射b——我们称之为eval。a⇒b如果函数对象的任何其他候选对象可以唯一地映射到它，从而使其应用态射g因式分解，则该对象是最好的eval。根据我们的排名，该对象比任何其他对象都要好。

The third part of the universal construction is selecting the object that is universally the best. Let’s call this object a⇒b (think of this as a symbolic name for one object, not to be confused with a Haskell typeclass constraint — I’ll discuss different ways of naming it later). This object comes with its own application — a morphism from (a⇒b)×a to b — which we will call eval. The object a⇒b is the best if any other candidate for a function object can be uniquely mapped to it in such a way that its application morphism g factorizes through eval. This object is better than any other object according to our ranking.

通用函数对象的定义。这与上面的图相同，但现在对象a⇒b是通用的。

The definition of the universal function object. This is the same diagram as above, but now the object a⇒b is universal.

正式：

Formally:

eval :: ((a⇒b) × a) -> b

eval :: ((a⇒b) × a) -> b

g :: z × a -> b

g :: z × a -> b

h :: z -> (a⇒b)

h :: z -> (a⇒b)

g = eval ∘ (h × id)

g = eval ∘ (h × id)

当然，不能保证a⇒b任何一对对象a和b给定范畴中都存在这样的对象。但在Set中总是如此。此外，在Set中，该对象与 hom-set Set(a, b)同构。

Of course, there is no guarantee that such an object a⇒b exists for any pair of objects a and b in a given category. But it always does in Set. Moreover, in Set, this object is isomorphic to the hom-set Set(a, b).

这就是为什么在 Haskell 中，我们将函数类型解释a->b为分类函数对象a⇒b。

This is why, in Haskell, we interpret the function type a->b as the categorical function object a⇒b.

10.2柯里化

10.2 Currying

让我们再看一下函数对象的所有候选对象。然而，这一次，让我们将态射视为两个变量和 的g函数。za

Let’s have a second look at all the candidates for the function object. This time, however, let’s think of the morphism g as a function of two variables, z and a.

g :: z × a -> b

g :: z × a -> b

作为乘积的态射就很接近于作为两个变量的函数。特别是，在Set中，g是来自一对值的函数，一个来自 set z，一个来自 set a。

Being a morphism from a product comes as close as it gets to being a function of two variables. In particular, in Set, g is a function from pairs of values, one from the set z and one from the set a.

另一方面，通用属性告诉我们，对于每个这样的态射，g都有一个h映射z到函数对象的唯一态射a⇒b。

On the other hand, the universal property tells us that for each such g there is a unique morphism h that maps z to a function object a⇒b.

h :: z -> (a⇒b)

h :: z -> (a⇒b)

在Set中，这仅意味着h是一个函数，它接受一个类型变量z并从ato返回一个函数b。这就形成了h一个高阶函数。因此，通用构造在两个变量的函数和一个变量返回函数的函数之间建立了一一对应关系。这种对应关系称为柯里化，并h称为 的柯里化版本g。

In Set, this just means that h is a function that takes one variable of type z and returns a function from a to b. That makes h a higher order function. Therefore the universal construction establishes a one-to-one correspondence between functions of two variables and functions of one variable returning functions. This correspondence is called currying, and h is called the curried version of g.

这种对应关系是一对一的，因为给定任何一个g都有一个唯一的h，并且给定任何你总是可以使用以下公式h重新创建两个参数函数：g

This correspondence is one-to-one, because given any g there is a unique h, and given any h you can always recreate the two-argument function g using the formula:

g = eval ∘ (h × id)

g = eval ∘ (h × id)

该函数g可以称为 的未柯里化版本h。

The function g can be called the uncurried version of h.

柯里化本质上是内置于 Haskell 语法中的。一个函数返回一个函数：

Currying is essentially built into the syntax of Haskell. A function returning a function:

a -> (b -> c)

a -> (b -> c)

通常被认为是两个变量的函数。这就是我们如何阅读不带括号的签名：

is often thought of as a function of two variables. That’s how we read the un-parenthesized signature:

a -> b -> c

a -> b -> c

这种解释在我们定义多参数函数的方式中很明显。例如：

This interpretation is apparent in the way we define multi-argument functions. For instance:

catstr :: String -> String -> String
catstr s s’ = s ++ s’

catstr :: String -> String -> String
catstr s s’ = s ++ s’

相同的函数可以写成一个返回一个函数的单参数函数——一个 lambda：

The same function can be written as a one-argument function returning a function — a lambda:

catstr’ s = \s’ -> s ++ s’

catstr’ s = \s’ -> s ++ s’

这两个定义是等价的，并且任一定义都可以部分应用于一个参数，生成一个单参数函数，如下所示：

These two definitions are equivalent, and either can be partially applied to just one argument, producing a one-argument function, as in:

greet :: String -> String
greet = catstr “Hello “

greet :: String -> String
greet = catstr “Hello “

严格来说，两个变量的函数是采用一对（产品类型）的函数：

Strictly speaking, a function of two variables is one that takes a pair (a product type):

(a, b) -> c

(a, b) -> c

在两种表示形式之间进行转换很简单，毫不奇怪，执行此操作的两个（高阶）函数被称为curry和uncurry：

It’s trivial to convert between the two representations, and the two (higher-order) functions that do it are called, unsurprisingly, curry and uncurry:

curry :: ((a, b)->c) -> (a->b->c)
curry f a b = f (a, b)

curry :: ((a, b)->c) -> (a->b->c)
curry f a b = f (a, b)

和

and

uncurry :: (a->b->c) -> ((a, b)->c)
uncurry f (a, b) = f a b

uncurry :: (a->b->c) -> ((a, b)->c)
uncurry f (a, b) = f a b

请注意，这curry是用于函数对象的通用构造的因式分解器。如果以这种形式重写，这一点尤其明显：

Notice that curry is the factorizer for the universal construction of the function object. This is especially apparent if it’s rewritten in this form:

factorizer :: ((a, b)->c) -> (a->(b->c))
factorizer g = \a -> (\b -> g (a, b))

factorizer :: ((a, b)->c) -> (a->(b->c))
factorizer g = \a -> (\b -> g (a, b))

（提醒一下：因式分解器从候选项生成因式分解函数。）

(As a reminder: A factorizer produces the factorizing function from a candidate.)

在非函数式语言（如 C++）中，柯里化是可能的，但并不简单。您可以将 C++ 中的多参数函数视为对应于采用元组的 Haskell 函数（不过，更令人困惑的是，在 C++ 中，您可以定义采用显式 的函数，以及可变参数函数和采用初始值设定项列表的函数）std::tuple。

In non-functional languages, like C++, currying is possible but nontrivial. You can think of multi-argument functions in C++ as corresponding to Haskell functions taking tuples (although, to confuse things even more, in C++ you can define functions that take an explicit std::tuple, as well as variadic functions, and functions taking initializer lists).

您可以使用模板部分应用 C++ 函数std::bind。例如，给定两个字符串的函数：

You can partially apply a C++ function using the template std::bind. For instance, given a function of two strings:

std::string catstr(std::string s1, std::string s2) {
    return s1 + s2;
}

std::string catstr(std::string s1, std::string s2) {
    return s1 + s2;
}

您可以定义一个字符串的函数：

you can define a function of one string:

using namespace std::placeholders;

auto greet = std::bind(catstr, "Hello ", _1);
std::cout << greet("Haskell Curry");

using namespace std::placeholders;

auto greet = std::bind(catstr, "Hello ", _1);
std::cout << greet("Haskell Curry");

Scala 比 C++ 或 Java 更实用，介于两者之间。如果您预计您定义的函数将被部分应用，您可以使用多个参数列表来定义它：

Scala, which is more functional than C++ or Java, falls somewhere in between. If you anticipate that the function you’re defining will be partially applied, you define it with multiple argument lists:

def catstr(s1: String)(s2: String) = s1 + s2

def catstr(s1: String)(s2: String) = s1 + s2

当然，这需要图书馆作者具有一定的远见或先见之明。

Of course that requires some amount of foresight or prescience on the part of a library writer.

10.3指数

10.3 Exponentials

a在数学文献中，函数对象，或者两个对象和之间的内部 hom 对象b，通常称为指数并用 表示ba。请注意，参数类型位于指数中。这种表示法一开始可能看起来很奇怪，但如果你考虑一下功能和产品之间的关系，它就很有意义了。我们已经看到，我们必须在内部 hom 对象的通用构造中使用乘积，但联系比这更深。

In mathematical literature, the function object, or the internal hom-object between two objects a and b, is often called the exponential and denoted by ba. Notice that the argument type is in the exponent. This notation might seem strange at first, but it makes perfect sense if you think of the relationship between functions and products. We’ve already seen that we have to use the product in the universal construction of the internal hom-object, but the connection goes deeper than that.

当您考虑有限类型（具有有限数量的值的类型，例如Bool、Char、甚至Int或）之间的函数时，这一点最为明显Double。这些函数至少在原则上可以完全记忆或转化为可供查找的数据结构。这就是函数（即态射）与函数类型（即对象）之间等价的本质。

This is best seen when you consider functions between finite types — types that have a finite number of values, like Bool, Char, or even Int or Double. Such functions, at least in principle, can be fully memoized or turned into data structures to be looked up. And this is the essence of the equivalence between functions, which are morphisms, and function types, which are objects.

例如，（纯）函数 fromBool完全由一对值指定：一个对应于False，另一个对应于True。Bool比如说，从 到 的所有可能函数的集合是所有sInt对的集合。Int这与产品相同Int × Int，或者，在符号上有点创意，Int2.

For instance a (pure) function from Bool is completely specified by a pair of values: one corresponding to False, and one corresponding to True. The set of all possible functions from Bool to, say, Int is the set of all pairs of Ints. This is the same as the product Int × Int or, being a little creative with notation, Int2.

再举个例子，让我们看看 C++ 类型char，它包含 256 个值（HaskellChar更大，因为 Haskell 使用 Unicode）。C++ 标准库中有几个函数通常是使用查找来实现的。isupper类似或 的函数isspace是使用表实现的，相当于 256 个布尔值的元组。元组是一种乘积类型，因此我们正在处理 256 个布尔值的乘积：bool × bool × bool × ... × bool。我们从算术中知道，迭代乘积定义了幂。如果你“乘”bool自身 256（或char）次，你就得到, 或 的bool幂。charboolchar

For another example, let’s look at the C++ type char, which contains 256 values (Haskell Char is larger, because Haskell uses Unicode). There are several functions in the part of the C++ Standard Library that are usually implemented using lookups. Functions like isupper or isspace are implemented using tables, which are equivalent to tuples of 256 Boolean values. A tuple is a product type, so we are dealing with products of 256 Booleans: bool × bool × bool × ... × bool. We know from arithmetics that an iterated product defines a power. If you “multiply” bool by itself 256 (or char) times, you get bool to the power of char, or boolchar.

定义为 256 元组的类型中有多少个值bool？正好 2 ²⁵⁶。char这也是从到的不同函数的数量bool，每个函数对应一个唯一的 256 元组。bool您可以类似地计算出从到的函数数量char为 256 ²，依此类推。在这些情况下，函数类型的指数表示法非常有意义。

How many values are there in the type defined as 256-tuples of bool? Exactly 2²⁵⁶. This is also the number of different functions from char to bool, each function corresponding to a unique 256-tuple. You can similarly calculate that the number of functions from bool to char is 256², and so on. The exponential notation for function types makes perfect sense in these cases.

我们可能不想完全记忆intor中的函数double。但是函数和数据类型之间的等价性（即使并不总是实用）是存在的。还有无限的类型，例如列表、字符串或树。对这些类型的函数的热切记忆将需要无限的存储空间。但 Haskell 是一种惰性语言，因此惰性求值（无限）数据结构和函数之间的界限是模糊的。这种函数与数据的二元性解释了 Haskell 函数类型与分类指数对象的识别——这更符合我们对数据的看法。

We probably wouldn’t want to fully memoize a function from int or double. But the equivalence between functions and data types, if not always practical, is there. There are also infinite types, for instance lists, strings, or trees. Eager memoization of functions from those types would require infinite storage. But Haskell is a lazy language, so the boundary between lazily evaluated (infinite) data structures and functions is fuzzy. This function vs. data duality explains the identification of Haskell’s function type with the categorical exponential object — which corresponds more to our idea of data.

10.4笛卡尔闭范畴

10.4 Cartesian Closed Categories

尽管我将继续使用集合范畴作为类型和函数的模型，但值得一提的是，有一个更大的范畴系列可以用于此目的。这些范畴称为笛卡尔闭合，Set只是此类范畴的一个示例。

Although I will continue using the category of sets as a model for types and functions, it’s worth mentioning that there is a larger family of categories that can be used for that purpose. These categories are called cartesian closed, and Set is just one example of such a category.

笛卡尔封闭范畴必须包含：

A cartesian closed category must contain:

1. 终端对象，
2. The terminal object,
3. 任何一对物体的乘积，以及
4. A product of any pair of objects, and
5. 任何一对对象的指数。
6. An exponential for any pair of objects.

如果您将指数视为迭代乘积（可能无限次），那么您可以将笛卡尔闭范畴视为任意数量的支持乘积。特别是，终端对象可以被认为是零个对象的乘积——或者对象的零次方。

If you consider an exponential as an iterated product (possibly infinitely many times), then you can think of a cartesian closed category as one supporting products of an arbitrary arity. In particular, the terminal object can be thought of as a product of zero objects — or the zero-th power of an object.

从计算机科学的角度来看，笛卡尔封闭范畴的有趣之处在于它们为简单类型的 lambda 演算提供了模型，该演算构成了所有类型编程语言的基础。

What’s interesting about cartesian closed categories from the perspective of computer science is that they provide models for the simply typed lambda calculus, which forms the basis of all typed programming languages.

最终对象和乘积有其对偶：初始对象和余积。笛卡尔封闭范畴，也支持这两者，并且其中乘积可以分布在余积上

The terminal object and the product have their duals: the initial object and the coproduct. A cartesian closed category that also supports those two, and in which product can be distributed over coproduct

a × (b + c) = a × b + a × c
(b + c) × a = b × a + c × a

a × (b + c) = a × b + a × c
(b + c) × a = b × a + c × a

称为双笛卡尔闭范畴。我们将在下一节中看到双笛卡尔封闭范畴（其中Set是一个主要示例）具有一些有趣的属性。

is called a bicartesian closed category. We’ll see in the next section that bicartesian closed categories, of which Set is a prime example, have some interesting properties.

10.5指数和代数数据类型

10.5 Exponentials and Algebraic Data Types

将函数类型解释为指数非常适合代数数据类型的方案。事实证明，高中代数中与数字 0 和 1、和、乘积和指数相关的所有基本恒等式在任何双笛卡尔闭范畴论中几乎保持不变，分别针对初始和最终对象、余积、乘积和指数。我们还没有工具来证明它们（例如附加词或米田引理），但我还是将它们列在这里，作为有价值的直觉的来源。

The interpretation of function types as exponentials fits very well into the scheme of algebraic data types. It turns out that all the basic identities from high-school algebra relating numbers zero and one, sums, products, and exponentials hold pretty much unchanged in any bicartesian closed category theory for, respectively, initial and final objects, coproducts, products, and exponentials. We don’t have the tools yet to prove them (such as adjunctions or the Yoneda lemma), but I’ll list them here nevertheless as a source of valuable intuitions.

a0 = 1

a0 = 1

1a = 1

1a = 1

a1 = a

a1 = a

ab+c = ab × ac

ab+c = ab × ac

f :: Either Int Double -> String

f :: Either Int Double -> String

f (Left n)  = if n < 0 then "Negative int" else "Positive int"
f (Right x) = if x < 0.0 then "Negative double" else "Positive double"

f (Left n)  = if n < 0 then "Negative int" else "Positive int"
f (Right x) = if x < 0.0 then "Negative double" else "Positive double"

(ab)c = ab×c

(ab)c = ab×c

(a × b)c = ac × bc

(a × b)c = ac × bc

10.6库里-霍华德同构

10.6 Curry-Howard Isomorphism

我已经提到了逻辑数据类型和代数数据类型之间的对应关系。类型Void和单元类型()对应的是 false 和 true。积类型和和类型对应于逻辑合取 ∧ (AND) 和析取 ⋁ (OR)。在这个方案中，我们刚刚定义的函数类型对应于逻辑蕴涵⇒。换句话说，该类型a->b可以理解为“if a then b”。

I have already mentioned the correspondence between logic and algebraic data types. The Void type and the unit type () correspond to false and true. Product types and sum types correspond to logical conjunction ∧ (AND) and disjunction ⋁ (OR). In this scheme, the function type we have just defined corresponds to logical implication ⇒. In other words, the type a->b can be read as “if a then b.”

根据库里-霍华德同构，每种类型都可以被解释为一个命题——一个可能为真或为假的陈述或判断。如果该类型有人居住，则这样的命题被认为是真；如果没有，则该命题被认为是假的。特别地，如果与其对应的函数类型被占据，则逻辑蕴涵为真，这意味着存在该类型的函数。因此，函数的实现就是定理的证明。编写程序相当于证明定理。让我们看几个例子。

According to the Curry-Howard isomorphism, every type can be interpreted as a proposition — a statement or a judgment that may be true or false. Such a proposition is considered true if the type is inhabited and false if it isn’t. In particular, a logical implication is true if the function type corresponding to it is inhabited, which means that there exists a function of that type. An implementation of a function is therefore a proof of a theorem. Writing programs is equivalent to proving theorems. Let’s see a few examples.

让我们以eval在函数对象的定义中引入的函数为例。它的签名是：

Let’s take the function eval we have introduced in the definition of the function object. Its signature is:

eval :: ((a -> b), a) -> b

eval :: ((a -> b), a) -> b

它采用由函数及其参数组成的对，并生成适当类型的结果。这是态射的 Haskell 实现：

It takes a pair consisting of a function and its argument and produces a result of the appropriate type. It’s the Haskell implementation of the morphism:

eval :: (a⇒b) × a -> b

eval :: (a⇒b) × a -> b

它定义了函数类型a⇒b（或指数对象ba）。让我们使用 Curry-Howard 同构将此签名转换为逻辑谓词：

which defines the function type a⇒b (or the exponential object ba). Let’s translate this signature to a logical predicate using the Curry-Howard isomorphism:

((a ⇒ b) ∧ a) ⇒ b

((a ⇒ b) ∧ a) ⇒ b

您可以这样理解此语句： 如果、 和的b后继项为真，则必定为真。这具有完美的直觉意义，自古以来就被称为“肯定前件”( modus ponens)。我们可以通过实现函数来证明这个定理：aab

Here’s how you can read this statement: If it’s true that b follows from a, and a is true, then b must be true. This makes perfect intuitive sense and has been known since antiquity as modus ponens. We can prove this theorem by implementing the function:

eval :: ((a -> b), a) -> b
eval (f, x) = f x

eval :: ((a -> b), a) -> b
eval (f, x) = f x

f如果您给我一对由接受a和返回的函数以及type 的b具体值组成的对，我可以通过简单地将函数应用于来生成 type 的具体值。通过实现这个函数，我刚刚证明了该类型是有人居住的。因此，在我们的逻辑中，肯定前件是正确的。xabfx((a -> b), a) -> b

If you give me a pair consisting of a function f taking a and returning b, and a concrete value x of type a, I can produce a concrete value of type b by simply applying the function f to x. By implementing this function I have just shown that the type ((a -> b), a) -> b is inhabited. Therefore modus ponens is true in our logic.

一个公然错误的谓词怎么样？例如：如果aorb为真，则a一定为真。

How about a predicate that is blatantly false? For instance: if a or b is true then a must be true.

a ⋁ b ⇒ a

a ⋁ b ⇒ a

这显然是错误的，因为你可以选择一个a是假的，一个b是真的，这是一个反例。

This is obviously wrong because you can chose an a that is false and a b that is true, and that’s a counter-example.

使用 Curry-Howard 同构将此谓词映射到函数签名，我们得到：

Mapping this predicate into a function signature using the Curry-Howard isomorphism, we get:

Either a b -> a

Either a b -> a

a尽管您可以尝试，但您无法实现此函数 -如果使用该值调用您，则无法生成该类型的值Right。（请记住，我们正在谈论纯函数。）

Try as you may, you can’t implement this function — you can’t produce a value of type a if you are called with the Right value. (Remember, we are talking about pure functions.)

最后我们来了解一下该函数的含义absurd：

Finally, we come to the meaning of the absurd function:

absurd :: Void -> a

absurd :: Void -> a

考虑到Void转化为 false，我们得到：

Considering that Void translates into false, we get:

false ⇒ a

false ⇒ a

任何事情都源于虚假（ex falso quodlibet）。这是 Haskell 中该语句（函数）的一个可能的证明（实现）：

Anything follows from falsehood (ex falso quodlibet). Here’s one possible proof (implementation) of this statement (function) in Haskell:

absurd (Void a) = absurd a

absurd (Void a) = absurd a

其中Void定义为：

where Void is defined as:

newtype Void = Void Void

newtype Void = Void Void

一如既往，这种类型Void很棘手。此定义使得无法构造一个值，因为为了构造一个值，您需要提供一个值。因此，该函数absurd永远无法被调用。

As always, the type Void is tricky. This definition makes it impossible to construct a value because in order to construct one, you would need to provide one. Therefore, the function absurd can never be called.

这些都是有趣的例子，但是库里-霍华德同构有实际的一面吗？日常编程中可能不会。但也有像 Agda 或 Coq 这样的编程语言，它们利用 Curry-Howard 同构来证明定理。

These are all interesting examples, but is there a practical side to Curry-Howard isomorphism? Probably not in everyday programming. But there are programming languages like Agda or Coq, which take advantage of the Curry-Howard isomorphism to prove theorems.

计算机不仅帮助数学家完成工作，而且正在彻底改变数学的基础。该领域最新的热门研究课题称为同伦类型理论，是类型理论的产物。它充满了布尔值、整数、乘积和余积、函数类型等等。而且，似乎是为了消除任何疑虑，该理论正在 Coq 和 Agda 中得到阐述。计算机正在以不止一种方式彻底改变世界。

Computers are not only helping mathematicians do their work — they are revolutionizing the very foundations of mathematics. The latest hot research topic in that area is called Homotopy Type Theory, and is an outgrowth of type theory. It’s full of Booleans, integers, products and coproducts, function types, and so on. And, as if to dispel any doubts, the theory is being formulated in Coq and Agda. Computers are revolutionizing the world in more than one way.

10.7参考书目

10.7 Bibliography

1. 拉尔夫·辛兹 (Ralph Hinze)、丹尼尔·WH·詹姆斯 (Daniel WH James)，同构推理！。本文包含我在本章中提到的范畴论中所有高中代数恒等式的证明。
2. Ralph Hinze, Daniel W. H. James, Reason Isomorphically!. This paper contains proofs of all those high-school algebraic identities in category theory that I mentioned in this chapter.

10.8致谢

10.8 Acknowledgments

我要感谢 Gershom Bazerman 检查我的数学和逻辑，以及 André van Meulebrouck，他在这一系列帖子中自愿提供编辑帮助。

I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.

11.1多态函数

11.1 Polymorphic Functions

我们讨论了函子（或更具体地说，endofunctors）在编程中的作用。它们对应于将类型映射到类型的类型构造函数。它们还将函数映射到函数，并且这种映射是由高阶函数fmap（或C++ 中的transform、then等）实现的。

We talked about the role of functors (or, more specifically, endofunctors) in programming. They correspond to type constructors that map types to types. They also map functions to functions, and this mapping is implemented by a higher order function fmap (or transform, then, and the like in C++).

为了构造一个自然转换，我们从一个对象开始，这里是一个类型，a。一个函子 ，F将其映射到类型F a。另一个函子 ，G将其映射到G a。alpha自然变换at的分量是从到 的a函数。在伪 Haskell 中：F aG a

To construct a natural transformation we start with an object, here a type, a. One functor, F, maps it to the type F a. Another functor, G, maps it to G a. The component of a natural transformation alpha at a is a function from F a to G a. In pseudo-Haskell:

alphaa :: F a -> G a

alphaa :: F a -> G a

自然变换是为所有类型定义的多态函数a：

A natural transformation is a polymorphic function that is defined for all types a:

alpha :: forall a . F a -> G a

alpha :: forall a . F a -> G a

在 Haskell 中是forall a可选的（实际上需要打开语言扩展ExplicitForAll）。通常，你会这样写：

The forall a is optional in Haskell (and in fact requires turning on the language extension ExplicitForAll). Normally, you would write it like this:

alpha :: F a -> G a

alpha :: F a -> G a

请记住，它实际上是由 参数化的一系列函数a。这是 Haskell 语法简洁性的另一个例子。C++ 中的类似构造会稍微冗长一些：

Keep in mind that it’s really a family of functions parameterized by a. This is another example of the terseness of the Haskell syntax. A similar construct in C++ would be slightly more verbose:

template<class A> G<A> alpha(F<A>);

template<class A> G<A> alpha(F<A>);

Haskell 的多态函数和 C++ 泛型函数之间存在更深刻的区别，这反映在这些函数的实现和类型检查的方式上。在 Haskell 中，必须为所有类型统一定义多态函数。一种公式必须适用于所有类型。这称为参数多态性。

There is a more profound difference between Haskell’s polymorphic functions and C++ generic functions, and it’s reflected in the way these functions are implemented and type-checked. In Haskell, a polymorphic function must be defined uniformly for all types. One formula must work across all types. This is called parametric polymorphism.

另一方面，C++ 默认支持临时多态性，这意味着模板不必针对所有类型进行良好定义。模板是否适用于给定类型是在实例化时决定的，其中用具体类型替换类型参数。类型检查被推迟，不幸的是，这通常会导致难以理解的错误消息。

C++, on the other hand, supports by default ad hoc polymorphism, which means that a template doesn’t have to be well-defined for all types. Whether a template will work for a given type is decided at instantiation time, where a concrete type is substituted for the type parameter. Type checking is deferred, which unfortunately often leads to incomprehensible error messages.

在C++中，还有函数重载和模板特化的机制，允许对不同类型对同一函数进行不同的定义。在 Haskell 中，此功能由类型类和类型族提供。

In C++, there is also a mechanism for function overloading and template specialization, which allows different definitions of the same function for different types. In Haskell this functionality is provided by type classes and type families.

Haskell 的参数多态性有一个意想不到的结果：任何以下类型的多态函数：

Haskell’s parametric polymorphism has an unexpected consequence: any polymorphic function of the type:

alpha :: F a -> G a

alpha :: F a -> G a

其中F和G是函子，自动满足自然性条件。这是分类符号（f是一个函数f::a->b）：

where F and G are functors, automatically satisfies the naturality condition. Here it is in categorical notation (f is a function f::a->b):

G f ∘ αa = αb ∘ F f

G f ∘ αa = αb ∘ F f

G在 Haskell 中，函子对态射的作用f是使用 实现的fmap。我将首先用伪 Haskell 编写它，并带有显式类型注释：

In Haskell, the action of a functor G on a morphism f is implemented using fmap. I’ll first write it in pseudo-Haskell, with explicit type annotations:

fmapG f . alphaa = alphab . fmapF f

fmapG f . alphaa = alphab . fmapF f

由于类型推断，这些注释不是必需的，并且以下等式成立：

Because of type inference, these annotations are not necessary, and the following equation holds:

fmap f . alpha = alpha . fmap f

fmap f . alpha = alpha . fmap f

这仍然不是真正的 Haskell——函数相等不能用代码来表达——但它是程序员可以在等式推理中使用的恒等式；或者由编译器来实现优化。

This is still not real Haskell — function equality is not expressible in code — but it’s an identity that can be used by the programmer in equational reasoning; or by the compiler, to implement optimizations.

自然性条件在 Haskell 中是自动的，这与“免费定理”有关。参数多态性用于定义 Haskell 中的自然变换，它对实现施加了非常强的限制——一个公式适用于所有类型。这些限制转化为关于此类函数的方程定理。对于变换函子的函数，自由定理是自然性条件。[您可以在我的博客《参数化：无用金钱》和《免费定理》中阅读有关免费定理的更多信息。]

The reason why the naturality condition is automatic in Haskell has to do with “theorems for free.” Parametric polymorphism, which is used to define natural transformations in Haskell, imposes very strong limitations on the implementation — one formula for all types. These limitations translate into equational theorems about such functions. In the case of functions that transform functors, free theorems are the naturality conditions. [You may read more about free theorems in my blog Parametricity: Money for Nothing and Theorems for Free.]

我之前提到的 Haskell 中函子的一种思考方式是将它们视为广义容器。我们可以继续这个类比，并将自然转换视为将一个容器的内容重新包装到另一个容器中的方法。我们不会触及项目本身：我们不会修改它们，也不会创建新的项目。我们只是将它们（其中一些）复制到一个新容器中，有时复制多次。

One way of thinking about functors in Haskell that I mentioned earlier is to consider them generalized containers. We can continue this analogy and consider natural transformations to be recipes for repackaging the contents of one container into another container. We are not touching the items themselves: we don’t modify them, and we don’t create new ones. We are just copying (some of) them, sometimes multiple times, into a new container.

自然性条件变成了这样的陈述：无论我们是否先修改项目，通过应用fmap，然后再重新打包；或者先重新打包，然后修改新容器中的项目，用它自己的fmap. fmap重新打包和ping这两个操作是正交的。“一个移动鸡蛋，另一个煮鸡蛋。”

The naturality condition becomes the statement that it doesn’t matter whether we modify the items first, through the application of fmap, and repackage later; or repackage first, and then modify the items in the new container, with its own implementation of fmap. These two actions, repackaging and fmapping, are orthogonal. “One moves the eggs, the other boils them.”

让我们看几个 Haskell 中自然变换的例子。第一个是列表函子和Maybe函子之间。它返回列表的头部，但前提是列表非空：

Let’s see a few examples of natural transformations in Haskell. The first is between the list functor, and the Maybe functor. It returns the head of the list, but only if the list is non-empty:

safeHead :: [a] -> Maybe a
safeHead [] = Nothing
safeHead (x:xs) = Just x

safeHead :: [a] -> Maybe a
safeHead [] = Nothing
safeHead (x:xs) = Just x

它是 中的多态函数a。它适用于任何类型a，没有任何限制，因此它是参数多态性的一个例子。因此，这是两个函子之间的自然变换。但为了说服自己，让我们验证一下自然性条件。

It’s a function polymorphic in a. It works for any type a, with no limitations, so it is an example of parametric polymorphism. Therefore it is a natural transformation between the two functors. But just to convince ourselves, let’s verify the naturality condition.

fmap f . safeHead = safeHead . fmap f

fmap f . safeHead = safeHead . fmap f

我们有两种情况需要考虑；一个空列表：

We have two cases to consider; an empty list:

fmap f (safeHead []) = fmap f Nothing = Nothing

fmap f (safeHead []) = fmap f Nothing = Nothing

safeHead (fmap f []) = safeHead [] = Nothing

safeHead (fmap f []) = safeHead [] = Nothing

和一个非空列表：

and a non-empty list:

fmap f (safeHead (x:xs)) = fmap f (Just x) = Just (f x)

fmap f (safeHead (x:xs)) = fmap f (Just x) = Just (f x)

safeHead (fmap f (x:xs)) = safeHead (f x : fmap f xs) = Just (f x)

safeHead (fmap f (x:xs)) = safeHead (f x : fmap f xs) = Just (f x)

我使用了 for 列表的实现fmap：

I used the implementation of fmap for lists:

fmap f [] = []
fmap f (x:xs) = f x : fmap f xs

fmap f [] = []
fmap f (x:xs) = f x : fmap f xs

和对于Maybe：

and for Maybe:

fmap f Nothing = Nothing
fmap f (Just x) = Just (f x)

fmap f Nothing = Nothing
fmap f (Just x) = Just (f x)

一个有趣的情况是其中一个函子是平凡Const函子。从函子到Const函子的自然转换看起来就像一个函数，其返回类型或其参数类型是多态的。

An interesting case is when one of the functors is the trivial Const functor. A natural transformation from or to a Const functor looks just like a function that’s either polymorphic in its return type or in its argument type.

例如，length可以被认为是从列表函子到Const Int函子的自然转换：

For instance, length can be thought of as a natural transformation from the list functor to the Const Int functor:

length :: [a] -> Const Int a
length [] = Const 0
length (x:xs) = Const (1 + unConst (length xs))

length :: [a] -> Const Int a
length [] = Const 0
length (x:xs) = Const (1 + unConst (length xs))

这里，unConst用于剥离Const构造函数：

Here, unConst is used to peel off the Const constructor:

unConst :: Const c a -> c
unConst (Const x) = x

unConst :: Const c a -> c
unConst (Const x) = x

当然，实际中length定义为：

Of course, in practice length is defined as:

length :: [a] -> Int

length :: [a] -> Int

这有效地掩盖了这是自然转变的事实。

which effectively hides the fact that it’s a natural transformation.

从函子中找到参数多态函数Const有点困难，因为它需要从无到有创建一个值。我们能做的最好的就是：

Finding a parametrically polymorphic function from a Const functor is a little harder, since it would require the creation of a value from nothing. The best we can do is:

scam :: Const Int a -> Maybe a
scam (Const x) = Nothing

scam :: Const Int a -> Maybe a
scam (Const x) = Nothing

我们已经见过的另一个常见函子是函子，它将在米田引理中发挥重要作用Reader。我将其定义重写为newtype：

Another common functor that we’ve seen already, and which will play an important role in the Yoneda lemma, is the Reader functor. I will rewrite its definition as a newtype:

newtype Reader e a = Reader (e -> a)

newtype Reader e a = Reader (e -> a)

它由两种类型参数化，但仅在第二种类型中（协变）函数：

It is parameterized by two types, but is (covariantly) functorial only in the second one:

instance Functor (Reader e) where  
   fmap f (Reader g) = Reader (\x -> f (g x))

instance Functor (Reader e) where  
   fmap f (Reader g) = Reader (\x -> f (g x))

对于每种类型e，您都可以定义一系列从Reader e到任何其他函子的自然转换f。f e稍后我们会看到，这个家族的成员总是与（米田引理）的元素一一对应。

For every type e, you can define a family of natural transformations from Reader e to any other functor f. We’ll see later that the members of this family are always in one to one correspondence with the elements of f e (the Yoneda lemma).

例如，考虑()具有一个元素的有点琐碎的单元类型()。函子Reader ()接受任何类型a并将其映射为函数类型()->a。这些只是从集合中选取单个元素的所有函数a。其中有多少个元素就有多少个a。现在让我们考虑从这个函子到Maybe函子的自然变换：

For instance, consider the somewhat trivial unit type () with one element (). The functor Reader () takes any type a and maps it into a function type ()->a. These are just all the functions that pick a single element from the set a. There are as many of these as there are elements in a. Now let’s consider natural transformations from this functor to the Maybe functor:

alpha :: Reader () a -> Maybe a

alpha :: Reader () a -> Maybe a

只有其中两个，dumb并且obvious：

There are only two of these, dumb and obvious:

dumb (Reader _) = Nothing

dumb (Reader _) = Nothing

和

and

obvious (Reader g) = Just (g ())

obvious (Reader g) = Just (g ())

（您唯一能做的g就是将其应用于单位值()。）

(The only thing you can do with g is to apply it to the unit value ().)

事实上，正如米田引理所预测的那样，它们对应于该Maybe ()类型的两个元素，即Nothing和Just ()。稍后我们会回到米田引理——这只是一个小预告。

And, indeed, as predicted by the Yoneda lemma, these correspond to the two elements of the Maybe () type, which are Nothing and Just (). We’ll come back to the Yoneda lemma later — this was just a little teaser.

11.2超越自然

11.2 Beyond Naturality

两个函子之间的参数多态函数（包括函子的边缘情况Const）始终是自然变换。由于所有标准代数数据类型都是函子，因此此类类型之间的任何多态函数都是自然转换。

A parametrically polymorphic function between two functors (including the edge case of the Const functor) is always a natural transformation. Since all standard algebraic data types are functors, any polymorphic function between such types is a natural transformation.

我们还可以使用函数类型，它们的返回类型是函数式的。我们可以使用它们来构建函子（如Reader函子）并定义作为高阶函数的自然变换。

We also have function types at our disposal, and those are functorial in their return type. We can use them to build functors (like the Reader functor) and define natural transformations that are higher-order functions.

但是，函数类型在参数类型中不协变。它们是逆变的。当然，逆变函子等价于相反范畴的协变函子。两个逆变函子之间的多态函数仍然是范畴意义上的自然变换，只不过它们作用于与 Haskell 类型相反范畴的函子。

However, function types are not covariant in the argument type. They are contravariant. Of course contravariant functors are equivalent to covariant functors from the opposite category. Polymorphic functions between two contravariant functors are still natural transformations in the categorical sense, except that they work on functors from the opposite category to Haskell types.

您可能还记得我们之前看过的逆变函子的示例：

You might remember the example of a contravariant functor we’ve looked at before:

newtype Op r a = Op (a -> r)

newtype Op r a = Op (a -> r)

该函子在 中是逆变的a：

This functor is contravariant in a:

instance Contravariant (Op r) where
    contramap f (Op g) = Op (g . f)

instance Contravariant (Op r) where
    contramap f (Op g) = Op (g . f)

我们可以编写一个多态函数，例如Op Bool从 to Op String：

We can write a polymorphic function from, say, Op Bool to Op String:

predToStr (Op f) = Op (\x -> if f x then "T" else "F")

predToStr (Op f) = Op (\x -> if f x then "T" else "F")

但由于两个函子不是协变的，这不是Hask中的自然变换。然而，因为它们都是逆变的，所以它们满足“相反”的自然性条件：

But since the two functors are not covariant, this is not a natural transformation in Hask. However, because they are both contravariant, they satisfy the “opposite” naturality condition:

contramap f . predToStr = predToStr . contramap f

contramap f . predToStr = predToStr . contramap f

请注意，由于 的签名，该函数的方向f必须与您使用的方向相反：fmapcontramap

Notice that the function f must go in the opposite direction than what you’d use with fmap, because of the signature of contramap:

contramap :: (b -> a) -> (Op Bool a -> Op Bool b)

contramap :: (b -> a) -> (Op Bool a -> Op Bool b)

是否存在不是函子的类型构造函数，无论是协变还是逆变？这是一个例子：

Are there any type constructors that are not functors, whether covariant or contravariant? Here’s one example:

a -> a

a -> a

这不是函子，因为a负（逆变）和正（协变）位置都使用相同的类型。您无法为这种类型实现fmapor 。contramap因此签名的函数：

This is not a functor because the same type a is used both in the negative (contravariant) and positive (covariant) position. You can’t implement fmap or contramap for this type. Therefore a function of the signature:

(a -> a) -> f a

(a -> a) -> f a

其中f是任意函子，不能是自然变换。有趣的是，有一个自然变换的概括，称为自然变换，可以处理这种情况。当我们讨论结束时我们会找到他们。

where f is an arbitrary functor, cannot be a natural transformation. Interestingly, there is a generalization of natural transformations, called dinatural transformations, that deals with such cases. We’ll get to them when we discuss ends.

11.3函子范畴

11.3 Functor Category

既然我们有了函子之间的映射（自然变换），那么很自然地就会问函子是否形成一个范畴的问题。确实如此！每对范畴 C 和 D 都有一个函子范畴。该范畴中的对象是从 C 到 D 的函子，态射是这些函子之间的自然变换。

Now that we have mappings between functors — natural transformations — it’s only natural to ask the question whether functors form a category. And indeed they do! There is one category of functors for each pair of categories, C and D. Objects in this category are functors from C to D, and morphisms are natural transformations between those functors.

我们必须定义两个自然变换的组合，但这很容易。自然变换的组成部分是态射，我们知道如何合成态射。

We have to define composition of two natural transformations, but that’s quite easy. The components of natural transformations are morphisms, and we know how to compose morphisms.

事实上，让我们采用从函子 F 到 G 的自然变换 α 。它在对象处的分量a是某种态射：

Indeed, let’s take a natural transformation α from functor F to G. Its component at object a is some morphism:

αa :: F a -> G a

αa :: F a -> G a

我们想将 α 与 β 组合起来，这是从函子 G 到 H 的自然变换。 β at 的分量a是一个态射：

We’d like to compose α with β, which is a natural transformation from functor G to H. The component of β at a is a morphism:

βa :: G a -> H a

βa :: G a -> H a

这些态射是可组合的，它们的组合是另一种态射：

These morphisms are composable and their composition is another morphism:

βa ∘ αa :: F a -> H a

βa ∘ αa :: F a -> H a

我们将使用这个态射作为自然变换 β ⋅ α 的分量——α 之后的两个自然变换 β 的组合：

We will use this morphism as the component of the natural transformation β ⋅ α — the composition of two natural transformations β after α:

(β ⋅ α)a = βa ∘ αa

(β ⋅ α)a = βa ∘ αa

仔细观察一下图表，我们就会相信这个组合的结果确实是从 F 到 H 的自然变换：

One (long) look at a diagram convinces us that the result of this composition is indeed a natural transformation from F to H:

H f ∘ (β ⋅ α)a = (β ⋅ α)b ∘ F f

H f ∘ (β ⋅ α)a = (β ⋅ α)b ∘ F f

自然变换的组合是结合律的，因为它们的分量（即正则态射）就其组合而言是结合律的。

Composition of natural transformations is associative, because their components, which are regular morphisms, are associative with respect to their composition.

最后，对于每个函子 F 都有一个恒等自然变换 1 _F，其分量是恒等态射：

Finally, for each functor F there is an identity natural transformation 1_F whose components are the identity morphisms:

idF a :: F a -> F a

idF a :: F a -> F a

因此，函子确实形成了一个范畴。

So, indeed, functors form a category.

关于符号的一句话。遵循 Saunders Mac Lane，我使用点来表示我刚才描述的那种自然变换构图。问题是有两种构成自然变换的方法。这称为垂直组合，因为函子通常在描述它的图中垂直堆叠。垂直组合对于定义函子范畴很重要。我将很快解释水平构图。

A word about notation. Following Saunders Mac Lane I use the dot for the kind of natural transformation composition I have just described. The problem is that there are two ways of composing natural transformations. This one is called the vertical composition, because the functors are usually stacked up vertically in the diagrams that describe it. Vertical composition is important in defining the functor category. I’ll explain horizontal composition shortly.

范畴 C 和 D 之间的函子范畴可写为Fun(C, D), or [C, D]，或有时写为DC。最后一个表示法表明函子范畴本身可能被视为某个其他范畴中的函数对象（指数）。情况确实如此吗？

The functor category between categories C and D is written as Fun(C, D), or [C, D], or sometimes as DC. This last notation suggests that a functor category itself might be considered a function object (an exponential) in some other category. Is this indeed the case?

让我们看一下到目前为止我们已经构建的抽象层次结构。我们从一个范畴开始，它是对象和态射的集合。范畴本身（或者严格来说，小范畴，其对象形成集合）本身就是更高级别范畴Cat中的对象。该范畴中的态射是函子。Cat中的 Hom-set是函子的集合。例如 Cat(C, D) 是两个范畴 C 和 D 之间的一组函子。

Let’s have a look at the hierarchy of abstractions that we’ve been building so far. We started with a category, which is a collection of objects and morphisms. Categories themselves (or, strictly speaking small categories, whose objects form sets) are themselves objects in a higher-level category Cat. Morphisms in that category are functors. A Hom-set in Cat is a set of functors. For instance Cat(C, D) is a set of functors between two categories C and D.

函子范畴 [C, D] 也是两个范畴之间的一组函子（加上作为态射的自然变换）。它的对象与Cat(C,D)的成员相同。而且，一个函子范畴作为一个范畴，它本身一定是Cat的一个对象（恰好两个小范畴之间的函子范畴本身就很小）。我们在范畴中的 Hom 集和同一范畴中的对象之间存在关系。这种情况与我们在上一节中看到的指数对象完全相同。让我们看看如何在Cat中构造后者。

A functor category [C, D] is also a set of functors between two categories (plus natural transformations as morphisms). Its objects are the same as the members of Cat(C, D). Moreover, a functor category, being a category, must itself be an object of Cat (it so happens that the functor category between two small categories is itself small). We have a relationship between a Hom-set in a category and an object in the same category. The situation is exactly like the exponential object that we’ve seen in the last section. Let’s see how we can construct the latter in Cat.

您可能还记得，为了构建指数，我们需要首先定义一个乘积。在Cat中，这相对容易，因为小范畴是对象的集合，并且我们知道如何定义集合的笛卡尔积。因此，产品范畴 C × D 中的对象只是一对对象 ，(c, d)一个来自 C，一个来自 D。类似地，两个这样的对之间的态射(c, d)和(c', d')是一对态射 ，(f, g)其中f :: c -> c'和g :: d -> d'。这些态射对按分量组合，并且始终存在一个恒等对，它只是一对恒等态射。长话短说，Cat是一个成熟的笛卡尔封闭范畴，其中任何一对范畴都存在一个指数对象 D ^{C 。}Cat中的“对象”指的是一个范畴，所以 D ^C是一个范畴，我们可以将其等同于 C 和 D 之间的函子范畴。

As you may remember, in order to construct an exponential, we need to first define a product. In Cat, this turns out to be relatively easy, because small categories are sets of objects, and we know how to define cartesian products of sets. So an object in a product category C × D is just a pair of objects, (c, d), one from C and one from D. Similarly, a morphism between two such pairs, (c, d) and (c', d'), is a pair of morphisms, (f, g), where f :: c -> c' and g :: d -> d'. These pairs of morphisms compose component-wise, and there is always an identity pair that is just a pair of identity morphisms. To make the long story short, Cat is a full-blown cartesian closed category in which there is an exponential object D^C for any pair of categories. And by “object” in Cat I mean a category, so D^C is a category, which we can identify with the functor category between C and D.

11.4 2-范畴

11.4 2-Categories

抛开这些，让我们仔细看看Cat。根据定义， Cat中的任何 Hom 集都是函子集。但是，正如我们所看到的，两个对象之间的函子具有比集合更丰富的结构。它们形成一个范畴，自然变换充当态射。由于函子在Cat中被视为态射，因此自然变换是态射之间的态射。

With that out of the way, let’s have a closer look at Cat. By definition, any Hom-set in Cat is a set of functors. But, as we have seen, functors between two objects have a richer structure than just a set. They form a category, with natural transformations acting as morphisms. Since functors are considered morphisms in Cat, natural transformations are morphisms between morphisms.

这个更丰富的结构是 2-范畴的一个例子，它是一个范畴的概括，其中除了对象和态射（在本文中可能称为 1-态射）之外，还有 2-态射，即态射之间的态射。

This richer structure is an example of a 2-category, a generalization of a category where, besides objects and morphisms (which might be called 1-morphisms in this context), there are also 2-morphisms, which are morphisms between morphisms.

对于Cat被视为 2 类的情况，我们有：

In the case of Cat seen as a 2-category we have:

• 对象：（小）范畴
• Objects: (Small) categories
• 1-态射：范畴之间的函子
• 1-morphisms: Functors between categories
• 2-态射：函子之间的自然变换。
• 2-morphisms: Natural transformations between functors.

我们有一个 Hom 范畴，而不是两个范畴 C 和 D 之间的 Hom 集合，即函子范畴 D ^C。^{我们有常规的函子组合：来自 D C}的函子 F与来自 E ^D的函子 G 组合，得到来自 E ^C的 G ∘ F 。但我们在每个 Hom 范畴内也有组合——函子之间自然变换或 2-态射的垂直组合。

Instead of a Hom-set between two categories C and D, we have a Hom-category — the functor category D^C. We have regular functor composition: a functor F from D^C composes with a functor G from E^D to give G ∘ F from E^C. But we also have composition inside each Hom-category — vertical composition of natural transformations, or 2-morphisms, between functors.

对于 2 范畴中的两种组合，出现了问题：它们如何相互作用？

With two kinds of composition in a 2-category, the question arises: How do they interact with each other?

让我们在Cat中选择两个函子或 1-态射：

Let’s pick two functors, or 1-morphisms, in Cat:

F :: C -> D
G :: D -> E

F :: C -> D
G :: D -> E

及其组成：

and their composition:

G ∘ F :: C -> E

G ∘ F :: C -> E

假设我们有两个自然变换 α 和 β，分别作用于函子 F 和 G：

Suppose we have two natural transformations, α and β, that act, respectively, on functors F and G:

α :: F -> F'
β :: G -> G'

α :: F -> F'
β :: G -> G'

请注意，我们不能对这一对应用垂直合成，因为 α 的目标与 β 的源不同。事实上，它们是两个不同函子范畴的成员：D ^C和 E ^D。然而，我们可以将复合应用于函子 F' 和 G'，因为 F' 的目标是 G' 的源 - 它是范畴 D。函子 G'∘ F' 和 G ∘ F 之间有什么关系？

Notice that we cannot apply vertical composition to this pair, because the target of α is different from the source of β. In fact they are members of two different functor categories: D ^C and E ^D. We can, however, apply composition to the functors F’ and G’, because the target of F’ is the source of G’ — it’s the category D. What’s the relation between the functors G’∘ F’ and G ∘ F?

有了 α 和 β，我们可以定义从 G ∘ F 到 G'∘ F' 的自然变换吗？让我画一下结构图。

Having α and β at our disposal, can we define a natural transformation from G ∘ F to G’∘ F’? Let me sketch the construction.

像往常一样，我们从 C 中的一个对象开始。a它的图像分为 D:F a和中的两个对象F'a。还有一个态射，α 的一个分量，连接这两个对象：

As usual, we start with an object a in C. Its image splits into two objects in D: F a and F'a. There is also a morphism, a component of α, connecting these two objects:

αa :: F a -> F'a

αa :: F a -> F'a

当从 D 到 E 时，这两个对象进一步分裂为四个对象：

When going from D to E, these two objects split further into four objects:

G (F a), G'(F a), G (F'a), G'(F'a)

G (F a), G'(F a), G (F'a), G'(F'a)

我们还有四个态射形成一个正方形。其中两个态射是自然变换 β 的组成部分：

We also have four morphisms forming a square. Two of these morphisms are the components of the natural transformation β:

βF a :: G (F a) -> G'(F a)
βF'a :: G (F'a) -> G'(F'a)

βF a :: G (F a) -> G'(F a)
βF'a :: G (F'a) -> G'(F'a)

_{另外两个是 α a}在两个函子下的图像（函子映射态射）：

The other two are the images of α_a under the two functors (functors map morphisms):

G αa :: G (F a) -> G (F'a)
G'αa :: G'(F a) -> G'(F'a)

G αa :: G (F a) -> G (F'a)
G'αa :: G'(F a) -> G'(F'a)

这是很多态射。我们的目标是找到从 到 的态射G (F a)，G'(F'a)它是连接两个函子 G ∘ F 和 G'∘ F' 的自然变换分量的候选者。事实上，从G (F a)到 ，我们可以采取的不是一条而是两条路径G'(F'a)：

That’s a lot of morphisms. Our goal is to find a morphism that goes from G (F a) to G'(F'a), a candidate for the component of a natural transformation connecting the two functors G ∘ F and G’∘ F’. In fact there’s not one but two paths we can take from G (F a) to G'(F'a):

G'αa ∘ βF a
βF'a ∘ G αa

G'αa ∘ βF a
βF'a ∘ G αa

对我们来说幸运的是，它们是相等的，因为我们形成的平方结果是 β 的自然平方。

Luckily for us, they are equal, because the square we have formed turns out to be the naturality square for β.

我们刚刚定义了从 G ∘ F 到 G'∘ F' 的自然变换的一个组成部分。只要您有足够的耐心，这种转变的自然性证明就非常简单。

We have just defined a component of a natural transformation from G ∘ F to G’∘ F’. The proof of naturality for this transformation is pretty straightforward, provided you have enough patience.

我们将这种自然变换称为α 和 β 的水平组合：

We call this natural transformation the horizontal composition of α and β:

β ∘ α :: G ∘ F -> G'∘ F'

β ∘ α :: G ∘ F -> G'∘ F'

再次，遵循Mac Lane，我使用小圆圈进行水平构图，尽管你也可能会在它的位置遇到星星。

Again, following Mac Lane I use the small circle for horizontal composition, although you may also encounter star in its place.

这是一个分类的经验法则：每次你有构图时，你都应该寻找一个范畴。我们有自然变换的垂直组合，它是函子范畴的一部分。但是横向构图呢？它属于什么范畴？

Here’s a categorical rule of thumb: Every time you have composition, you should look for a category. We have vertical composition of natural transformations, and it’s part of the functor category. But what about the horizontal composition? What category does that live in?

解决这个问题的方法是从侧面看Cat。不要将自然变换视为函子之间的箭头，而是范畴之间的箭头。自然变换位于两个范畴之间，这两个范畴通过它变换的函子连接起来。我们可以将其视为连接这两个范畴。

The way to figure this out is to look at Cat sideways. Look at natural transformations not as arrows between functors but as arrows between categories. A natural transformation sits between two categories, the ones that are connected by the functors it transforms. We can think of it as connecting these two categories.

让我们关注Cat的两个对象——范畴 C 和 D。连接 C 到 D 的函子之间有一组自然变换。这些自然变换是我们从 C 到 D 的新箭头。同样，有自然变换连接 D 到 E 的函子之间的变换，我们可以将其视为从 D 到 E 的新箭头。水平组合是这些箭头的组合。

Let’s focus on two objects of Cat — categories C and D. There is a set of natural transformations that go between functors that connect C to D. These natural transformations are our new arrows from C to D. By the same token, there are natural transformations going between functors that connect D to E, which we can treat as new arrows going from D to E. Horizontal composition is the composition of these arrows.

我们还有一个从 C 到 C 的恒等箭头。恒等自然变换将 C 上的恒等函子映射到其自身。请注意，水平构图的恒等式也是垂直构图的恒等式，但反之则不然。

We also have an identity arrow going from C to C. It’s the identity natural transformation that maps the identity functor on C to itself. Notice that the identity for horizontal composition is also the identity for vertical composition, but not vice versa.

最后，这两个组合满足交换律：

Finally, the two compositions satisfy the interchange law:

(β' ⋅ α') ∘ (β ⋅ α) = (β' ∘ β) ⋅ (α' ∘ α)

(β' ⋅ α') ∘ (β ⋅ α) = (β' ∘ β) ⋅ (α' ∘ α)

我将在这里引用桑德斯·麦克莱恩的话：读者可能喜欢写下证明这一事实所需的明显图表。

I will quote Saunders Mac Lane here: The reader may enjoy writing down the evident diagrams needed to prove this fact.

还有一种符号将来可能会派上用场。在Cat的这种新的横向解释中，有两种从一个对象到另一个对象的方法：使用函子或使用自然变换。然而，我们可以将函子箭头重新解释为一种特殊的自然变换：作用于该函子的恒等自然变换。所以你会经常看到这样的符号：

There is one more piece of notation that might come in handy in the future. In this new sideways interpretation of Cat there are two ways of getting from object to object: using a functor or using a natural transformation. We can, however, re-interpret the functor arrow as a special kind of natural transformation: the identity natural transformation acting on this functor. So you’ll often see this notation:

F ∘ α

F ∘ α

其中 F 是从 D 到 E 的函子，α 是从 C 到 D 的两个函子之间的自然变换。由于您无法使用自然变换来组合函子，因此这被解释为恒等自然变换的水平组合α 后为1 _F。

where F is a functor from D to E, and α is a natural transformation between two functors going from C to D. Since you can’t compose a functor with a natural transformation, this is interpreted as a horizontal composition of the identity natural transformation 1_F after α.

相似地：

Similarly:

α ∘ F

α ∘ F

_{是 1 F}之后 α 的水平合成。

is a horizontal composition of α after 1_F.

11.5结论

11.5 Conclusion

本书的第一部分到此结束。我们已经学习了范畴论的基本词汇。您可能会将对象和范畴视为名词；以及作为动词的态射、函子和自然变换。态射连接对象，函子连接范畴，自然变换连接函子。

This concludes the first part of the book. We’ve learned the basic vocabulary of category theory. You may think of objects and categories as nouns; and morphisms, functors, and natural transformations as verbs. Morphisms connect objects, functors connect categories, natural transformations connect functors.

但我们也看到，在一个抽象层次上表现为动作的东西，在下一个层次上变成了对象。一组态射变成一个函数对象。作为一个对象，它可以是另一个态射的源或目标。这就是高阶函数背后的想法。

But we’ve also seen that, what appears as an action at one level of abstraction, becomes an object at the next level. A set of morphisms turns into a function object. As an object, it can be a source or a target of another morphism. That’s the idea behind higher order functions.

函子将对象映射到对象，因此我们可以将其用作类型构造函数或参数类型。函子还映射态射，因此它是一个高阶函数 - fmap。有一些简单的函子，例如Const、积和余积，可用于生成多种代数数据类型。函数类型也是函数类型，包括协变和逆变，并且可用于扩展代数数据类型。

A functor maps objects to objects, so we can use it as a type constructor, or a parametric type. A functor also maps morphisms, so it is a higher order function — fmap. There are some simple functors, like Const, product, and coproduct, that can be used to generate a large variety of algebraic data types. Function types are also functorial, both covariant and contravariant, and can be used to extend algebraic data types.

函子可以被视为函子范畴中的对象。因此，它们成为态射的源和目标：自然变换。自然变换是一种特殊类型的多态函数。

Functors may be looked upon as objects in the functor category. As such, they become sources and targets of morphisms: natural transformations. A natural transformation is a special type of polymorphic function.

11.6挑战

11.6 Challenges

1. Maybe定义从函子到列表函子的自然变换。证明其自然性条件。
2. Define a natural transformation from the Maybe functor to the list functor. Prove the naturality condition for it.
3. Reader ()在和 列表函子之间定义至少两个不同的自然变换。()有多少种不同的列表？
4. Define at least two different natural transformations between Reader () and the list functor. How many different lists of () are there?
5. Reader Bool使用和继续前面的练习Maybe。
6. Continue the previous exercise with Reader Bool and Maybe.
7. 证明自然变换的水平合成满足自然性条件（提示：使用组件）。这是一个很好的图解练习。
8. Show that horizontal composition of natural transformation satisfies the naturality condition (hint: use components). It’s a good exercise in diagram chasing.
9. 写一篇短文，讲述你如何喜欢写下证明交换律所需的明显图表。
10. Write a short essay about how you may enjoy writing down the evident diagrams needed to prove the interchange law.

11. 为不同函子之间的变换的相反自然条件创建一些测试用例Op。这是一种选择：

    op :: Op Bool Int
    op = Op (\x -> x > 0)

    和

    f :: String -> Int
    f x = read x

12. Create a few test cases for the opposite naturality condition of transformations between different Op functors. Here’s one choice:

    op :: Op Bool Int
    op = Op (\x -> x > 0)

    and

    f :: String -> Int
    f x = read x

11.7致谢

11.7 Acknowledgments

我要感谢 Gershom Bazerman 检查我的数学和逻辑，以及 André van Meulebrouck，他一直自愿提供编辑帮助。

I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help.

12.1第二部分介绍